Sandbox

Veja também: README · Autenticação

#Como acessar

1. Primeiro, a CardV precisa aprovar a sua empresa.
2. Entre no Portal e escolha Sandbox no topo da página. Não é possível entrar direto no Sandbox.
3. No primeiro acesso, a CardV cria a sua conta no Sandbox. Ela tem o mesmo Merchant ID e 1.000 USD em dinheiro de teste.
4. No Sandbox, um Owner cria e exibe uma chave de API do Sandbox. Chaves do Live não funcionam aqui.
5. Opcional: configure um webhook no Sandbox. Ele tem o próprio segredo de assinatura.

#O que é separado

• O Sandbox tem as próprias chaves, carteira, pedidos, webhooks, lista de IPs permitidos e registro de auditoria.
• As configurações não são compartilhadas. Configure chaves, webhooks e a lista de IPs permitidos em cada ambiente.
• Pedidos no Sandbox nunca compram produtos reais. Os códigos de teste não podem ser resgatados.
• O dinheiro de teste não vale nada. No Sandbox não dá para adicionar saldo, sacar nem transferir para o Live.
• Se o dinheiro de teste acabar, peça mais ao suporte da CardV.

#Dinheiro de teste

Os pedidos usam o dinheiro de teste do mesmo jeito que os pedidos no Live usam dinheiro real. Pedidos de teste com falha são reembolsados da mesma forma. As movimentações do dinheiro de teste aparecem na página de transações do Portal.

#Catálogo de teste

• O catálogo do Sandbox é pequeno e só tem produtos de teste.
• Os IDs de SKU são diferentes dos do Live. Busque sempre com GET/skus no Sandbox.
• Nunca copie IDs do Sandbox para a configuração do Live, nem o contrário.
• Preços, disponibilidade e velocidade de entrega no Sandbox não são iguais aos do Live.

#Checklist de testes

• GET/account mostra o seu Merchant ID e "api_access_enabled": true.
• GET/balance funciona.
• Você consegue percorrer as páginas de GET/skus e só pede SKUs available.
• Um pedido assinado dá certo. Uma assinatura errada recebe HTTP 403.
• Você envia expected_unit_price em todos os itens do pedido.
• Um pedido de SKU de valor variável com amount funciona (se o Sandbox tiver algum).
• Enviar o mesmo pedido duas vezes (nonce novo, mesmo corpo e mesmo número de pedido) retorna HTTP 200 com o mesmo order_id. O saldo é cobrado só uma vez.
• O mesmo número de pedido com um corpo diferente retorna HTTP 400 em external_order_id.
• Depois de um timeout, o seu código reenvia o mesmo pedido em vez de criar um número de pedido novo.
• Você lê deliveries[].display_fields e entrega esses dados ao cliente.
• Você trata failed, refunded e partially_succeeded.
• O seu código de webhook passa no vetor de teste e depois em um webhook real do Sandbox. Duplicados são ignorados.
• Você espera o Retry-After depois de um HTTP 429.
• Os seus logs não têm chaves de API, assinaturas, códigos nem dados de conta dos clientes.

#Checklist para entrar em produção

• Crie uma chave de API Live no Portal do Live. Guarde-a no cofre de segredos de produção.
• Na configuração, troque a URL base para https://b2b.cardv.net/api/v1.
• Carregue o catálogo do Live e associe os seus produtos aos IDs de SKU do Live.
• Adicione saldo à carteira do Live pelo Portal. Configure o alerta de saldo baixo.
• Opcional: adicione os IPs dos seus servidores à lista de IPs permitidos do Live.
• Configure um webhook no Live e instale o segredo de assinatura dele.
• Confirme com a CardV os seus limites de pedido e de requisições.
• Faça um pedido pequeno no Live. Confira a cobrança, os códigos e o webhook. Depois aumente o volume aos poucos.
• Concilie todos os dias com a página de transações e as exportações do Portal.
• Ative a verificação em duas etapas para todos os Owners.

#Solução de problemas

HTTP 403 error code: 1010

O Sandbox fica atrás de um serviço de borda de rede. Alguns clientes HTTP recebem HTTP 403 com o texto simples error code: 1010. A requisição nem chegou à CardV, então trocar a chave ou a assinatura não resolve.

• Defina um User-Agent claro.
• Se continuar, envie ao suporte da CardV o IP do seu servidor, o User-Agent e o horário.
• Nunca passe a testar no Live por causa disso.