HOMOLOGAÇÃO

Sandbox de pagamentos: como homologar antes de vender

Sandbox de pagamentos é um ambiente de teste que simula partes da integração sem movimentar uma venda real. Ele serve para validar contrato técnico, estados e exceções. Como simulação não reproduz toda a rede, a homologação deve terminar com testes controlados no ambiente de produção.

Por Equipe MarchaRevisado em 20 de julho de 20269 min de leitura

O que o sandbox deve provar

Valide autenticação, criação, consulta, cancelamento, reembolso, eventos e erros documentados. Confirme que pedido e transação permanecem relacionados e que o sistema não depende de tempos irreais.

Monte uma matriz de cenários

  • Aprovação e pendência.
  • Recusa e dado inválido.
  • Expiração e cancelamento.
  • Evento duplicado e fora de ordem.
  • Timeout e repetição.
  • Estorno total e parcial, quando disponíveis.

Dados e ambientes separados

Use chaves, banco e filas distintos. Identifique registros de teste e nunca copie segredo de produção para ferramentas pessoais. Documente quem pode promover uma configuração.

Checklist de entrada em produção

Revise URLs, segredos, limites, alertas, dashboards, suporte e rollback. Faça uma transação controlada e acompanhe até a conciliação.

Planeje sua homologação com a Marcha

Se você quer avaliar esse desenho na sua operação, fale com um especialista da Marcha. A recomendação final depende do modelo de negócio, do fluxo financeiro e da análise cadastral e comercial.

Plano de cenários

Crie casos para sucesso, recusa, pendência, expiração, timeout, evento repetido, evento fora de ordem, estorno parcial e credencial inválida. Relacione cada cenário ao resultado esperado no pedido, financeiro e atendimento.

Use dados fictícios autorizados e automatize os fluxos críticos. Um teste que apenas retorna sucesso não valida a operação completa.

Diferenças entre sandbox e produção

Documente recursos ausentes, códigos simulados, prazos e comportamento de webhooks. Produção pode ter latência, regras e participantes que o ambiente de testes não reproduz. Não assuma equivalência.

Antes do volume real, faça smoke test controlado com credenciais, URLs e observabilidade de produção. Defina limite e plano de reversão.

Isolamento e higiene de dados

Separe credenciais, bancos, filas e endpoints. Identifique visualmente o ambiente e impeça envio de dados reais ao sandbox. Segredos de teste também devem ser protegidos para evitar abuso.

Limpe dados conforme política e mantenha fixtures determinísticas. Testes devem poder repetir sem depender de estado deixado por outra equipe.

Perguntas frequentes

Sandbox movimenta dinheiro?

Normalmente não, mas confirme a documentação e o ambiente usado.

Resultado do sandbox garante produção?

Não. Rede, risco e participantes reais podem se comportar de forma diferente.

Preciso testar erros?

Sim. Exceções são parte central da integração.

Quando posso liberar o checkout?

Após critérios técnicos, operacionais, cadastrais e comerciais estarem aprovados.

Sandbox aprovado significa que posso liberar tudo?

Não. Ele demonstra cenários simulados. Ainda é preciso validar configuração, segurança, observabilidade e diferenças de produção. Faça liberação gradual, acompanhe transações e tenha reconciliação e rollback. Requisitos operacionais e comerciais também precisam estar concluídos.

Quais evidências devo guardar dos testes antes de produção?

Registre cenário, dados fictícios, resultado esperado, requisições e eventos relevantes, estado final nos sistemas e versão testada. Inclua falhas e retomadas, não apenas capturas de sucesso. Associe cada requisito a pelo menos um teste e identifique limitações do sandbox. Essas evidências ajudam na revisão técnica, mas não substituem smoke test controlado e monitoramento após a publicação. Registre também o responsável pela execução, a data e qualquer desvio aceito para revisão posterior.