Sandbox de pagamentos: como testar a integração antes de ir para produção

Está a ler:

Sandbox de pagamentos: como testar a integração antes de ir para produção

Do sandbox à produção: como testar uma integração de pagamentos que não falha

Uma integração de pagamentos não está pronta só porque o primeiro pagamento correu bem. Os problemas aparecem nos outros casos, e é para os apanhar que serve um sandbox de pagamentos: uma encomenda criada para um pagamento recusado, um cliente cobrado duas vezes porque carregou duas vezes em “Pagar”, ou uma referência Multibanco paga que continua “pendente” na loja.

Neste último caso, o cliente pagou, mas não recebe a confirmação da compra; a encomenda não é expedida; e a equipa de apoio passa o dia a responder a emails e a corrigir estados à mão. Tudo porque a notificação de pagamento não foi bem processada.

Sandbox vs. produção: o que muda

Um sandbox de pagamentos é um ambiente de testes que funciona como a plataforma de pagamentos real, mas sem dinheiro real. Na easypay, a diferença está no endereço da API e nas credenciais:

Sandbox Produção
URL da API https://api.test.easypay.pt/2.0 https://api.prod.easypay.pt/2.0
Dinheiro real Não Sim
Credenciais De teste (disponíveis na documentação) Geradas na sua conta easypay
Limites de pedidos Mais flexíveis Aplicados
Dados Podem ser reiniciados Permanentes

Passar para produção é, na prática, trocar o URL e as credenciais. Mas um teste bem-sucedido em sandbox não garante, por si só, que tudo corre bem em produção. Acompanhe as primeiras transações reais de perto.

Os cenários que tem de testar no sandbox de pagamentos

1. Pagamentos aprovados, recusados e pendentes

Confirme que um pagamento recusado nunca dá origem a uma encomenda paga, e que um pagamento pendente não é tratado como pago antes da confirmação. Cada meio de pagamento confirma de forma diferente, por isso teste-os um a um.

2. MB WAY: aceite, recusado ou expirado

No MB WAY, o cliente aprova o pagamento no telemóvel. Teste o que acontece quando aceita, quando recusa e quando não responde a tempo. A loja deve libertar o stock, mostrar uma mensagem clara e permitir tentar de novo.

3. Cartões: autenticação 3D Secure, recusas e capturas

Nos cartões, teste os pagamentos aprovados e recusados, mas também a autenticação 3D Secure: o que acontece quando o cliente não conclui a validação no banco ou fecha a janela a meio. Se usa autorização e captura em separado (por exemplo, para só cobrar quando expede a encomenda), confirme que a captura é feita pelo valor certo e que as autorizações não capturadas não ficam esquecidas.

4.Apple Pay, Google Pay e Samsung Pay: o botão certo no dispositivo certo

As carteiras digitais usam um cartão do cliente, por isso pagamentos aprovados, recusados e reembolsos funcionam como nos cartões. Mas há testes próprios: confirme que o botão de cada carteira só aparece nos dispositivos e browsers compatíveis, que o checkout continua a funcionar quando não aparece, e que o domínio da loja está registado para o Apple Pay. Teste também o que acontece quando o cliente cancela a autenticação no telemóvel (Face ID, impressão digital ou código).

5. IBAN virtual: transferências associadas ao cliente certo

Com o IBAN virtual, cada cliente ou fatura tem um IBAN próprio, e o pagamento chega por transferência bancária: em segundos, se for imediata, ou no dia útil seguinte, se for uma transferência normal. Teste se a sua integração associa corretamente cada transferência ao cliente ou à fatura certa.

6. Multibanco e outros pagamentos assíncronos

Na referência Multibanco, o pagamento pode chegar horas ou dias depois de o cliente sair do checkout. A encomenda só deve mudar de estado quando chegar a notificação de pagamento (webhook).

7. Notificações duplicadas, atrasadas ou fora de ordem

Os webhooks podem chegar mais do que uma vez, ou numa ordem diferente da esperada. A sua integração deve processar cada notificação uma única vez e confirmar sempre o estado final do pagamento.

8. Falhas de rede e pedidos repetidos

O que acontece se a ligação falhar a meio do pagamento, ou se o cliente carregar duas vezes no botão? Use idempotência para que um pedido repetido não crie um segundo pagamento.

9. Reembolsos, cancelamentos e capturas

Teste reembolsos totais e parciais, cancelamentos e, se usar autorização e captura em separado, a captura de pagamentos autorizados. Cada operação tem de atualizar o estado certo nos seus sistemas.

10. Credenciais e dados

Use apenas dados de teste, mantenha as credenciais de sandbox e de produção separadas, e guarde-as em variáveis de ambiente ou num gestor de segredos, nunca no código.

Como testar no sandbox de pagamentos da easypay

O sandbox de pagamentos da easypay é gratuito e permite testar os meios de pagamento portugueses de ponta a ponta:

  • Cartões: números de cartão de teste para simular pagamentos aprovados e recusados.
  • MB WAY: pagamentos de teste sem precisar de confirmar num telemóvel real.
  • Multibanco: referências que pode marcar como pagas no backoffice, para testar o pagamento assíncrono e a notificação.
  • Webhooks: receba as notificações de alteração de estado tal como em produção.

Para começar, basta usar as credenciais de teste da documentação e o URL de sandbox:

curl -L -X POST 'https://api.test.easypay.pt/2.0/single' \
  -H 'AccountId: <TEST_ACCOUNT_ID>' \
  -H 'ApiKey: <TEST_API_KEY>' \
  -H 'Content-Type: application/json' \
  --data-raw '{ ... }'

Se usa WooCommerce ou Magento, também pode testar os plugins da easypay em modo de testes antes de ativar os pagamentos reais.

Checklist antes de passar para produção

  • Todos os meios de pagamento da loja foram testados (cartões, MB WAY, Multibanco, IBAN Virtual…).
  • Pagamentos recusados, pendentes e expirados deixam a encomenda no estado certo.
  • Nos cartões, a autenticação 3D Secure e as capturas foram testadas.
  • As carteiras digitais – wallets (Apple Pay, Google Pay, Samsung Pay) foram testadas em diferentes dispositivos e browsers.
  • No IBAN virtual, as transferências são associadas ao cliente certo.
  • Os webhooks são processados uma única vez, mesmo duplicados ou fora de ordem.
  • Pedidos repetidos não criam pagamentos duplicados (idempotência).
  • Reembolsos, cancelamentos e capturas foram validados.
  • As credenciais e o URL foram trocados pelos de produção.
  • Há monitorização e alertas para os primeiros pagamentos reais.

Sempre que possível, automatize estes testes para os repetir a cada alteração ao código.

Comece a testar hoje

Uma integração fiável começa antes do primeiro pagamento real. Use as credenciais de teste e comece já no sandbox da easypay, ou fale com a nossa equipa para encontrar a solução de pagamentos certa para o seu negócio.

[Ver documentação e credenciais de teste] · [Pedir proposta comercial]