Pular para o conteúdo principal

Gateway de Pagamento Fictício para Testes: Provedor Dummy do Casdoor, Modo de Teste Stripe e Sandbox PayPal

· Leitura de 10 min
Yang Luo
Yang Luo
Casdoor Maintainer

Um gateway de pagamento fictício é um provedor de pagamento que aceita todos os checkouts como pagos sem contatar um banco ou rede de cartões, permitindo testar pedidos, assinaturas e entrega sem dinheiro e sem conta no gateway. O Casdoor inclui um: o provedor de pagamento Dummy. Adicione-o a um produto, compre o produto, e o Casdoor registra o pagamento e o pedido como Paid, inicia a assinatura e escreve a transação, tudo sem sair do seu servidor. Use Dummy no desenvolvimento, e alterne para um sandbox de fornecedor (modo de teste Stripe, sandbox PayPal, sandbox Paddle) no staging, onde você também precisa de cartões recusados, 3-D Secure e redirecionamentos reais.

Dummy, Balance e sandboxes de fornecedores num relance​

ProvedorAmbiente de testeComo o Casdoor escolhe teste ou produçãoTipo de provedor Casdoor
DummyNenhum necessário, todo pagamento tem sucessoSempre simuladoDummy
BalanceInterno, financiado por um produto de recargaSempre internoBalance
StripeSandbox com chaves sk_test_ / pk_test_Pelas chaves que você insereStripe
PayPalApps sandbox e contas sandboxrunmode diferente de prod usa o sandboxPayPal
PaddleConta sandbox separada em sandbox-vendors.paddle.comrunmode diferente de prod usa sandbox-api.paddle.comPaddle
AdyenAmbiente de teste (checkout-test.adyen.com)runmode diferente de prod usa o ambiente de testeAdyen
AirWallexSeparate sandbox accountrunmode other than prod calls api.sandbox.airwallex.comAirWallex
Lemon SqueezyModo de teste da loja com chaves de API de modo de testePela chave de API que você insereLemon Squeezy
FastSpringVitrine de teste com .test. no hostPelo Host que você insereFastSpring
PolarSandbox em sandbox.polar.shDefina o Host do provedor como https://sandbox-api.polar.shPolar

runmode é a opção em conf/app.conf (ou a variável de ambiente runmode) descrita na referência de configuração. Seu padrão é dev, então um Casdoor recém-instalado fala com os sandboxes de PayPal, Paddle, Adyen e AirWallex até que você defina para prod.

O que significa uma transação fictícia​

Uma transação fictícia passa pelos mesmos registros de uma compra real (pedido, pagamento, assinatura, lançamento no livro-razão), mas não movimenta dinheiro. É diferente de uma transação sandbox. Um sandbox ainda chama a API do fornecedor, mostra a página de checkout do fornecedor e envia webhooks; apenas o dinheiro é falso. Uma transação fictícia nunca sai do seu sistema.

Essa diferença decide o que cada um pode testar. Um gateway fictício é bom para sua própria lógica: o plano concede a função correta, o pedido aparece, o cupom conta como usado, o usuário chega na página certa. Um sandbox é bom para a integração: credenciais, redirecionamentos, recusas de cartão, desafios de autenticação e entrega de webhooks. Você precisa de ambos, em etapas diferentes.

Como o provedor Dummy do Casdoor funciona​

O provedor Dummy não possui configurações nem página de pagamento. Aqui está o fluxo completo no master do Casdoor:

  1. Quando o usuário paga, a chamada Pay do provedor retorna a página de resultado do Casdoor como URL de pagamento. Ela empacota o preço e a moeda no ID do pedido em vez de criar qualquer coisa em um fornecedor.
  2. O Casdoor armazena o pagamento no estado Created e envia o navegador diretamente para a página de resultado. Não há formulário de cartão, falso ou não.
  3. A página de resultado vê um pagamento Created e chama POST /api/notify-payment cerca de um segundo depois.
  4. A chamada Notify do provedor sempre responde Paid, com o preço que foi empacotado anteriormente, então a verificação de preço passa.
  5. O Casdoor então executa o caminho normal de sucesso: o pagamento e o pedido tornam-se Paid, as assinaturas criadas para o pagamento são atualizadas, uma transação Purchase é escrita, o estoque do produto é reduzido e um cupom no pedido é marcado como usado. Se o produto for um produto de recarga, uma transação Recharge também adiciona o valor ao saldo do usuário.

Então sim, o Dummy marca o pedido como pago imediatamente, e o usuário vê a página de sucesso sem etapas intermediárias.

Duas limitações decorrem desse design. O Dummy não pode falhar: não há maneira de fazê-lo retornar Canceled, Timeout ou Error, então os caminhos de falha precisam de um sandbox. E o Dummy não pode renovar: o Casdoor permite apenas renovação automática para Balance e Stripe, então uma assinatura comprada com Dummy sempre tem a renovação automática desativada.

Em um novo banco de dados, o Casdoor cria um provedor Dummy integrado chamado provider_payment_dummy na organização admin, ao lado de um provedor Balance integrado. Você também pode adicionar o seu próprio: em Identity > Providers, defina Category como Payment e Type como Dummy.

Mantenha o Dummy fora da produção​

/api/notify-payment is open to anonymous callers, because real gateways call it without a Casdoor session. For a real provider that is safe, since Notify checks the payment with the vendor. Dummy checks nothing and reports Paid, so for a Dummy payment Casdoor only accepts the call from the payment's own user or an admin of its organization. That still leaves the main risk: any product that lists Dummy in its Payment providers shows it at checkout, and any signed-in user who picks it gets the product for free. Remove Dummy from every product before you go live, and do not put it on products in an organization that real users can reach.

Balance: a carteira interna que você pode financiar com o Dummy​

O provedor Balance permite que os usuários paguem a partir do saldo da conta. O Casdoor verifica o saldo primeiro, deduz o preço e marca o pagamento e o pedido como Paid na mesma solicitação. O Balance é um recurso real de produção, não uma ferramenta de teste, mas combina bem com o Dummy: coloque o Dummy em um produto de recarga, faça uma "carga" em um usuário de teste, e o saldo será creditado sem dinheiro envolvido.

Isso é importante para assinaturas, porque o Balance é um dos dois provedores que suportam renovação automática. Com Dummy mais Balance, você pode testar todo o ciclo de renovação em um laptop sem conta de gateway.

Sandboxes de fornecedores para staging​

Stripe. O Stripe separa dados de teste e ao vivo por chaves: chaves de sandbox começam com pk_test_ e sk_test_, chaves ao vivo com pk_live_ e sk_live_, e objetos em um modo não são visíveis no outro. O Casdoor usa quaisquer chaves que você colocar no provedor Stripe; runmode não altera nada para o Stripe. Os cartões de teste do Stripe cobrem os caminhos que o Dummy não consegue: 4242 4242 4242 4242 tem sucesso, 4000 0000 0000 0002 é recusado, e 4000 0000 0000 3220 requer 3-D Secure. Use qualquer data de expiração futura e qualquer CVC. Os termos do Stripe proíbem testes no modo ao vivo com detalhes reais de cartão.

PayPal. O sandbox do PayPal é um ambiente separado com seus próprios apps e contas de teste. O PayPal cria uma conta pessoal padrão e uma conta empresarial padrão do sandbox quando você faz login pela primeira vez no painel do desenvolvedor; você paga com a pessoal. Crie o app no modo sandbox, coloque suas credenciais no provedor PayPal, e mantenha runmode em dev.

Paddle. O sandbox é uma conta separada em sandbox-vendors.paddle.com com suas próprias chaves e produtos; nada é compartilhado com o ao vivo. Os cartões de teste do Paddle incluem 4242 4242 4242 4242 (sucesso) e 4000 0000 0000 0002 (recusado).

Lemon Squeezy has a test mode per store, and API keys created in test mode only see test data. FastSpring test orders go through a test storefront: insert .test. into the store host, for example yourstore.test.onfastspring.com, and enter that as the provider's Host. Polar has a sandbox with its own tokens; set the provider's Host to https://sandbox-api.polar.sh to use it, and leave Host empty for live Polar. Alipay in Casdoor is also hard-wired to production.

Um plano de teste para produtos, planos e assinaturas do Casdoor​

Desenvolvimento, com Dummy​

  1. Crie um produto e adicione o Dummy aos seus Payment providers.
  2. Crie um plano para esse produto e uma página de preços que o liste (veja a visão geral de preços).
  3. Como usuário de teste, abra a página de preços e compre o plano. Verifique se o pagamento e o pedido estão Paid, a assinatura está Active, e uma transação Purchase aparece no usuário.
  4. Faça login como o usuário e verifique se a função do plano entrou em vigor na sua aplicação.
  5. Se o plano tiver Is exclusive ativado, compre-o novamente e espere o erro de que o usuário já tem uma assinatura ativa.
  6. Aplique um cupom no checkout e verifique se seu uso é registrado.
  7. Crie um produto de recarga com Dummy, carregue o usuário de teste, depois compre o plano com Balance e Auto renew ativado.
  8. Para testar a renovação sem esperar um mês, edite o End time da assinatura em sua página de edição para que termine dentro de 24 horas. O Casdoor verifica as assinaturas uma vez por hora; espere Renewal state Renewed e uma nova assinatura para o próximo período. Depois compre o plano novamente com um saldo muito baixo para o próximo período, mova seu tempo final da mesma maneira, e espere Failed com o motivo em Renewal message. A documentação de assinaturas descreve as regras exatas.

Staging, com um sandbox​

  1. Execute o staging com runmode = dev e use apenas credenciais de sandbox ou teste.
  2. Substitua Dummy pelo provedor que você utilizará em produção, configurado com suas chaves de sandbox.
  3. Repita a compra e verifique se o navegador vai para o checkout do fornecedor e retorna à página de resultados do Casdoor.
  4. Com Stripe, pague uma vez com o cartão de recusa e outra com o cartão 3-D Secure, verificando os estados de pagamento e pedido para cada caso.
  5. Com Stripe e Auto renew ativado, o Casdoor salva o cartão no checkout e cobra por conta própria na renovação, então o truque do horário final acima funciona também no sandbox.

Entrando em produção​

Remova Dummy de todos os produtos, defina runmode = prod se usar PayPal, Paddle, Adyen ou AirWallex, e substitua pelas chaves de produção. Verifique os registros de pagamento dos primeiros pedidos reais.

Se você também testar o email de cadastro no mesmo ambiente, um capturador de email local mantém essas mensagens fora das caixas de entrada reais; veja MailHog vs Mailpit.

Referências​