Testes

Uma chave de teste não movimenta dinheiro real — mas quase todo o resto é real.

As chaves de teste

As suas chaves existem em duas famílias: sk_live_… e sk_test_…. A chave utilizada marca a operação durante toda a sua vida; nada transfere uma operação de uma família para a outra.

Com uma chave de teste:

• nenhum fornecedor é chamado. Responde sempre uma simulação em seu lugar — uma execução de teste não consegue alcançar um canal real nem perturbá-lo.
• o livro-razão, as liquidações e as notificações transacionais ficam excluídos. Nenhum movimento contabilístico, nenhum total de liquidação, nenhum SMS ou e-mail ao pagador.
• todo o resto é real: a cadeia de aceitação, os seus webhooks, os seus registos de desenvolvedor, as suas linhas de reporting e a totalidade dos controlos de risco.

Montantes mágicos

Os dois últimos dígitos do montante escolhem o resultado. É a única forma de ensaiar os caminhos de falha, que um canal em bom estado nunca produz.

O montante termina em	O que acontece
99	Recusado no envio, de forma definitiva. A classe «número inválido» — não repita
98	Recusado no envio, de forma temporária. A classe «falha do canal» — repetir faz sentido
97	Aceite e depois falhado. Primeiro pending, depois failed
qualquer outra coisa	Aceite e depois success

Aplica-se igualmente a cobranças, pagamentos, reembolsos e anulações.

O caso 97 é o que realmente vale a pena ensaiar

É a sequência que as integrações deixam passar: o seu webhook recebe pending, marca a encomenda como «a aguardar pagamento», e depois chega failed e tem de desfazer o que pending fez. Sem uma forma de a provocar, a primeira vez que esse caminho é percorrido é em produção.

Um montante que codificou uma falha falha de ponta a ponta: uma operação não pode ao mesmo tempo recusar e ter êxito, por mais vezes que a leia.

Identidades de teste

Os controlos de conformidade ensaiam-se da mesma maneira, com identidades mágicas. Apenas correspondem a operações de teste.

Identidade	O que ensaia	O que deve ver
+221700000001 — «Test Sanctionne Fort»	Correspondência forte com uma lista de sanções	O pagamento é recusado.
«Test Sanctionne Nom Seul» (apenas nome, sem número)	Correspondência apenas pelo nome	Aceite e depois retido para análise — ver abaixo
+221700000003 — «Test Personne Politiquement Exposee»	Pessoa politicamente exposta	Análise reforçada, não uma recusa
+221700000004 — «Test Identite Mineure»	Identidade conhecida como menor	Recusado num corredor restrito (jogo, apostas), aceite nos restantes

Conjunto de identidades em vigor: fixture-2026-09-13-1. É idêntico em todos os ambientes e muda por versão — um teste escrito contra um conjunto com nome permanece reproduzível.

Um nome por si só nunca é uma recusa

A segunda linha surpreende, e é deliberado: uma correspondência apenas pelo nome não detém um pagamento. Os sobrenomes são partilhados; recusar com base no nome significaria recusar muitíssimas pessoas por o escreverem corretamente. Por isso o pagamento é aceite e retido para análise, e a sua integração deve tratar isso como uma espera, não como uma falha.

Uma recusa exige um identificador forte: um número, um documento.

⚠️ Estas identidades não são pessoas reais e nunca correspondem a um pagamento em produção. Usá-las com uma chave sk_live_ não produz nada: são identidades de ensaio, e nada mais.

O que pode ensaiar

• risk.status a passar para review e para held, tanto no webhook como numa leitura;
• os eventos payment.held e payment.released;
• um processo de conformidade aberto na via de teste: visível para si, e que nunca chega à nossa equipa de conformidade nem a qualquer total regulamentar.

O que uma execução de teste não mostra

Três limites, ditos com clareza em vez de descobertos mais tarde:

1. Nenhum movimento contabilístico. O livro-razão está fora do perímetro de teste, pelo que nada relativo a um saldo disponível, a uma retenção ou a uma libertação de fundos pode ser verificado aqui.
2. Os tempos não são os de produção. A simulação não tem pagador: a confirmação vem de uma varredura com a sua própria cadência, não de alguns segundos após um código USSD. Teste a transição, nunca o relógio.
3. As notificações transacionais não são enviadas. Nem ao pagador nem a si.

O que não deve fazer

• Não deduza os seus tempos de produção a partir dos tempos de teste. Ver o ponto 2.
• Não trate pending como uma falha, nem em teste nem em produção.
• Nunca copie uma identidade de teste para os seus dados de produção. Ali não corresponde a nada, e um dado de ensaio num registo real é uma pista falsa para quem o ler depois.