Cenários de pagamento

O sandbox de um fornecedor decide o que o seu pagamento faz. Aqui quem decide é você, dando ao pagamento o nome do resultado que você quer.

Chame o portador do cartão de insufficient_funds e o pagamento é recusado por esse motivo, no código do próprio PSP. Chame ele de approve e o pagamento passa, seja qual for o número de cartão que você mandou.

Dê nome ao portador do cartão

O nome do portador é a primeira coisa conferida, e a comparação ignora maiúsculas e minúsculas. Use approve para uma autorização limpa, ou qualquer uma destas recusas:

• Estado do cartão: expired_card, invalid_card, blocked_card, restricted_card, lost_card, stolen_card
• Dinheiro: insufficient_funds, withdrawal_amount_exceeded, invalid_amount
• Fraude e checagens: fraud, acquirer_fraud, issuer_suspected_fraud, avs_declined, cvc_declined
• Recusado ou desviado: declined, referral, transaction_not_permitted, not_supported, not_3ds_authenticated
• Falhas do outro lado: acquirer_error, issuer_unavailable

Todo provedor responde às mesmas palavras e devolve o código dele para elas. Você escreve o teste uma vez, e adicionar um segundo PSP não quer dizer aprender um segundo vocabulário.

Pagamentos que não têm nome

As carteiras, os cartões salvos e o PayPal não têm portador para nomear. Outros dois gatilhos chegam neles:

• O e-mail de quem paga, declined@example.com para uma recusa simples, ou nobalance@example.com para saldo insuficiente.
• O valor 99, na moeda que você estiver mandando, também para saldo insuficiente.

3D Secure

Quatro nomes mandam um pagamento com cartão para a autenticação em vez de autorizar direto:

• require_3ds para num desafio.
• require_3ds_frictionless passa a autenticação sem desafio nenhum.
• require_3ds_fingerprint coleta primeiro uma impressão do dispositivo, e depois desafia.
• require_3ds_fingerprint_frictionless coleta a impressão e depois passa.

Um provedor que não oferece 3D Secure aprova esses em vez de falhar, então o mesmo teste consegue rodar contra um PSP que não tem esse fluxo.

Veja Visão geral do backend de pagamentos para saber como o desafio em si é.

Os dados de teste do próprio fornecedor

Cada PSP mantém os valores da documentação dele por cima do conjunto compartilhado. Os nomes de portador DECLINED, REFERRAL e CARD_EXPIRED da Adyen funcionam, e os números de cartão de teste e os prefixos BIN publicados dela também. Se o seu time já tem uma página com cartões de teste do fornecedor, eles continuam funcionando aqui.

Qual gatilho ganha

Um pagamento pega o primeiro gatilho que corresponde, nesta ordem:

1. Nome do portador do cartão
2. E-mail de quem paga
3. Número do cartão
4. Valor
5. Prefixo BIN do cartão
6. Método de pagamento

Essa ordem é o que deixa um nome útil. Um nome ganha de um número de cartão, então chamar o portador de approve empurra um cartão que seria recusado, e chamar ele de stolen_card recusa um cartão que passaria numa boa.

Ver ao que um provedor responde

Você não precisa deixar esta página aberta para saber o que um backend vai fazer. Abra o backend, vá em Cenários, e escolha um provedor.

De fábrica é o que aquele provedor traz, incluindo os cartões de teste e os nomes reservados dele.

Compartilhado é a base a que todo provedor de todo backend responde, que é a lista do começo desta página.

As duas são só leitura. Elas estão ali para serem lidas e copiadas.

Quando a lista que vem junto não basta

Escreva a sua. Um cenário diz a quais requisições ele corresponde e o que deve voltar, e os seus são testados antes de qualquer um de fábrica.

Veja Escreva os seus próprios cenários.

Para onde ir agora

• Escreva os seus próprios cenários
• Visão geral do backend de pagamentos
• Atividade do backend