Cartões de teste
Em vez de números de cartão, você escolhe o cenário. Isso cobre aprovação, recusas e a indisponibilidade do provedor que exige reconciliação.
Não existe campo de número de cartão
A API e o checkout hospedado não aceitam número, validade nem código de segurança. O cenário é o único dado do cartão.
{
"payment_method": { "type": "card", "test_card": "unavailable_then_approved" }
}Os 5 cenários
test_card | Resposta do confirm | Estado final | Notas |
|---|---|---|---|
approved | 200, status succeeded | succeeded | Aprovado na hora; Charge e ledger na mesma transação. |
declined_insufficient_funds | 402 PAYMENT_DECLINED | failed (failure_code INSUFFICIENT_FUNDS) | Recusa definitiva por saldo. |
declined_generic | 402 PAYMENT_DECLINED | failed (failure_code CARD_DECLINED) | Recusa definitiva genérica. |
unavailable_then_approved | 202, status processing | succeeded após a reconciliação | O provedor “cai” e o resultado fica desconhecido; a reconciliação descobre que foi aprovado. |
unavailable_then_declined | 202, status processing | failed após a reconciliação | Resultado desconhecido que a reconciliação resolve como recusa. |
Resultado desconhecido e reconciliação
Um timeout do provedor não significa recusa: o dinheiro pode ter sido capturado. Por isso o PaymentIntent fica processing, a Wolf emite payment.reconciliation_required e a reconciliação automática consulta o provedor (a cada poucos minutos) até ter o resultado. Então emite payment.reconciled, cujo data.status traz o estado final (succeeded ou failed).
- Nunca crie outro pagamento para o mesmo pedido enquanto o primeiro está
processing. - Para não esperar o ciclo automático no sandbox, force com
POST /v1/simulator/payment-intents/{id}/reconcile. - No checkout hospedado a sessão é concluída pelo evento, mesmo que o comprador feche a página.