Testar o Stripe Billing

Saiba como testar a integração do Billing.

Teste detalhadamente toda a integração antes de disponibilizá-la aos clientes ou usá-la em atividades do modo de produção. Use os recursos desta página como complemento das diretrizes organizacionais (por exemplo, manuais de operação, verificações de qualidade ou listas de verificação de desenvolvimento) para ajudar a determinar se a integração está pronta para uso em produção.

Princípios da transição para produção

Antes de usar a integração no modo de produção, confira estas listas de verificação da Stripe:

Veja a seguir um fluxo de integração típico.

Para integrações de assinaturas e receitas recorrentes, verifique se pelo menos estes componentes funcionam como esperado.

A tabela mostra as notificações de evento para cada componente. A integração pode ser configurada para ouvir esses eventos com webhooks. Leia este guia para saber mais sobre notificações de eventos e testes.

Componente	Descrição	Eventos
Registro do cliente	Verifique se a integração pode coletar corretamente os dados necessários para criar um registro Customer na Stripe. Os clientes podem informar esses dados no Checkout do Payment Links, no Elements ou em uma forma de pagamento completamente personalizada criada com a API Stripe. Qualquer que seja a forma utilizada, verifique se o objeto Customer está armazenado na Stripe. Você pode usar a Dashboard ou a API para ver e gerenciar Customers.	`customer.created` `customer.subscription.created`
Faturamento	As assinaturas geram faturas no final de cada ciclo de faturamento. Dependendo da forma de pagamento, você pode enviar faturas para cobrar pagamentos pós-pagos. Verifique se a integração cria e envia faturas da forma esperada. Leia este guia para saber mais sobre a criação e o gerenciamento de faturas para assinaturas. Use clocks de teste para simular ciclos de faturamento, incluindo a geração e o envio de faturas. Leia o guia de clocks de teste para saber mais sobre os casos de uso específicos que você pode testar.	`invoice.created` `invoice.finalized` `invoice.finalization_failed` `invoice.paid` `invoice.payment_action_required` `invoice.payment_failed` `invoice.upcoming` `invoice.updated`
Gerenciamento de assinaturas	Configure o portal do cliente para permitir que seus clientes gerenciem suas assinaturas e informações de cobrança. Para testá-lo, crie uma assinatura em uma área restrita. Em seguida, faça login no portal como usuário de teste e atualize a assinatura. Verifique o Dashboard ou a API para ver se a assinatura reflete a alteração do cliente. Leia o guia de integração para saber como configurar o portal do cliente.	`customer.subscription.deleted` `customer.subscription.paused` `customer.subscription.resumed` `customer.subscription.updated`
Avaliações	Ofereça aos clientes uma avaliação do seu serviço. Para testar se a configuração da avaliação está correta, crie um clock de teste. A assinatura deve gerar uma fatura com valor zero para o período da assinatura. Saiba como testar avaliações com clocks de teste. Para obter mais informações sobre o funcionamento das avaliações, leia o guia de avaliações de assinatura.	`customer.subscription.trial_will_end` `customer.subscription.updated`
Falhas de pagamento	Os pagamentos dos clientes podem falhar por diversos motivos. Verifique se a integração gerencia falhas, incluindo novas tentativas de pagamento Saiba como testar falhas de pagamento.	`invoice.finalization_failed` `invoice.payment_failed` `invoice.payment_action_required`

Clocks de teste

Os clocks de teste permitem simular objetos do Billing, como assinaturas, ao longo do tempo em uma área restrita. Assim, você não precisa esperar um ano para ver como a integração se comporta no caso de falha de pagamento de uma renovação anual. Não é preciso criar nenhum código com clocks de teste: é possível criar simulações no Dashboard. Você também pode acessá-los usando a API. Saiba mais sobre os clocks de teste e os seus casos de uso.

Testar períodos de avaliação de assinatura

Primeiro, siga estas instruções para começar a usar clocks de teste:

Em seguida, você pode começar a testar avaliações com clocks de teste. Vamos supor que você deseja que os clientes experimentem o produto gratuitamente em uma avaliação de sete dias antes de começarem a pagar. Para isso, você quer coletar antecipadamente os dados de pagamento. Para simular essa situação usando clocks de teste, siga estas instruções:

Crie um clock de teste com frozen_time definido como 1º de janeiro.
Adicione um cliente e inclua a forma de pagamento dele. Neste caso, use um cartão de teste .
Crie uma assinatura e adicione um período de avaliação gratuita de sete dias:

Para adicionar um período de avaliação a uma assinatura existente usando o Dashboard:

Encontre a assinatura a ser alterada.

Clique em Ações.
Clique em Atualizar assinatura.
Clique em Adicionar avaliação gratuita e informe 7 no campo Dias de avaliação gratuita.
Clique em Atualizar assinatura.

O estado de uma assinatura criada com um período de avaliação gratuita de sete dias é trialing. Com essa assinatura, também é criada uma fatura de US$ 0,00.
Adiante a data para 5 de janeiro para ver a notificação do evento customer.subscription.trial_will_end. A Stripe envia a notificação três dias antes do final da avaliação. Esse webhook pode ser usado para informar aos clientes que a avaliação termina em breve.
Adiante a data para 8 de janeiro. O estado da assinatura passa para paid e é criada uma fatura de 50 SEK.
Adiante a data para mais um ciclo (por exemplo, para 8 de fevereiro se a assinatura for mensal) para ver a renovação bem-sucedida da assinatura.

Testar períodos de avaliação sem clocks de teste

Testar notificações de webhook de assinatura

As integrações de assinatura dependem muito de webhooks. Você configura um endpoint de webhook no servidor e especifica quais eventos quer ouvir. A Stripe emite notificações para eventos como atualização ou cancelamento de assinaturas.

Teste webhooks criando assinaturas de teste reais ou acionando notificações de evento com a Stripe CLI ou no Dashboard.

Depois de configurar a Stripe CLI e vincular a sua conta Stripe, você pode acionar eventos do ciclo de vida da assinatura para testar a integração de webhooks. Quando você usa a Stripe CLI para acionar eventos, pode ver notificações de eventos assim que chegam ao servidor. Dessa forma, é possível verificar a integração de webhooks diretamente, sem túneis ou firewalls de rede.

Quando você usa a Stripe CLI ou o Dashboard para acionar eventos, o webhook recebe eventos com dados simulados, sem relação aos dados da assinatura. A forma mais confiável de testar notificações de webhooks é criar assinaturas de teste reais e gerenciar os eventos correspondentes.

A tabela a seguir descreve os eventos mais comuns relacionados a assinaturas e sugere ações para gerenciar os eventos, quando for o caso.



`customer.created`	Enviado quando um Customer é criado.
`customer.subscription.created`	Enviado quando a assinatura é criada. O `status` da assinatura pode ser `incomplete` se a autenticação do cliente for necessária para concluir o pagamento ou se você definir `payment_behavior` como `default_incomplete`. Para saber mais, consulte o comportamento do pagamento da assinatura.
`customer.subscription.deleted`	Enviado quando a assinatura do cliente termina.
`customer.subscription.paused`	Enviado quando o `status` de uma assinatura muda para `paused`. Por exemplo, isso é enviado quando uma assinatura é configurada para ser suspensa ao final de uma avaliação gratuita sem forma de pagamento. O faturamento só ocorre quando a assinatura é retomada. Não enviamos esse evento se o recebimento de pagamentos for suspenso porque as faturas continuam sendo criadas durante esse período.
`customer.subscription.resumed`	Enviado quando uma assinatura com status `paused` é retomada. Não se aplica quando a cobrança do pagamento é reiniciada.
`customer.subscription.trial_will_end`	Enviado três dias antes do final do período de avaliação. O evento é acionado quando o período de avaliação é inferior a três dias.
`customer.subscription.updated`	Enviado quando uma assinatura inicia ou é alterada. Por exemplo, o evento é acionado ao renovar uma assinatura, adicionar cupons, aplicar descontos, incluir itens de fatura ou alterar planos.
`entitlements.active_entitlement_summary.updated`	Enviado quando os direitos ativos de um cliente são atualizados. Quando receber esse evento, você pode provisionar ou cancelar o acesso aos recursos do produto. Leia mais sobre integração com direitos.
`invoice.created`	Enviado quando uma fatura é criada para uma assinatura nova ou em renovação. Se a Stripe não receber uma resposta positiva para `invoice.created`, a finalização de todas as faturas com cobrança automática será adiada por até 72 horas. Leia mais sobre a finalização de faturas. Responda à notificação enviando uma solicitação para a API finalizar uma fatura.
`invoice.finalized`	Enviado quando uma fatura é finalizada e está pronta para pagamento. Você pode enviar a fatura ao cliente. Para saber mais, consulte finalização de faturas. Dependendo da configuração, cobraremos automaticamente a forma de pagamento padrão ou tentaremos fazer a cobrança. Para saber mais, consulte e-mails após a finalização.
`invoice.finalization_failed`	Não foi possível finalizar a fatura. Leia o guia para saber como gerenciar falhas de finalização de faturas. Saiba mais sobre a finalização de faturas no guia de visão geral de faturas. Inspecione last_finalization_error da fatura para determinar a causa do erro. Se você usa o Stripe Tax, confira o campo automatic_tax do objeto Invoice. Se `automatic_tax[status]=requires_location_inputs`, não é possível finalizar a fatura e cobrar os pagamentos. Notifique o cliente e colete a localização do cliente obrigatória. Se `automatic_tax[status]=failed`, tente a solicitação outra vez mais tarde.
`invoice.paid`	Enviado quando a fatura é paga. Você pode provisionar acesso ao produto quando recebe este evento e `status` é `active`.
`invoice.payment_action_required`	Enviado quando a fatura exige autenticação do cliente. Saiba como gerenciar a assinatura quando a fatura exigir ação.
`invoice.payment_failed`	Houve uma falha no pagamento de uma fatura. O status do PaymentIntent muda para `requires_action`. O status da assinatura continua `incomplete` somente na primeira fatura da assinatura. Você pode tomar várias providências quando um pagamento falha: Avise o cliente. Saiba como configurar a assinatura para ativar o Smart Retries e outros recursos de recuperação de receitas. Se você usa PaymentIntents, colete os novos dados de pagamento e confirme o PaymentIntent. Atualize a forma de pagamento padrão na assinatura.
`invoice.upcoming`	Enviado alguns dias antes da renovação da assinatura. O número de dias é baseado no número definido para Próximos eventos de renovação no Dashboard. Para assinaturas existentes, a alteração do número de dias entra em vigor no próximo período de cobrança. Se necessário, você ainda pode adicionar outros itens de fatura.
`invoice.updated`	Enviado quando um pagamento é bem-sucedido ou falha. Se o pagamento for bem-sucedido, o atributo `paid` será definido como `true`, e `status` será `paid`. Se o pagamento falhar, `paid` será definido como `false`, e `status` permanecerá `open`. As falhas de pagamento também acionam um evento `invoice.payment_failed`.
`payment_intent.created`	Enviado quando um PaymentIntent é criado.
`payment_intent.succeeded`	Enviado quando um PaymentIntent conclui um pagamento.
`subscription_schedule.aborted`	Enviado quando um cronograma de assinatura é cancelado porque o pagamento inadimplente encerrou a assinatura relacionada.
`subscription_schedule.canceled`	Enviado quando um cronograma de assinatura é cancelado, o que também cancela qualquer assinatura associada ativa.
`subscription_schedule.completed`	Enviado quando todas as fases de um cronograma de assinatura são concluídas.
`subscription_schedule.created`	Enviado quando um novo cronograma de assinatura é criado.
`subscription_schedule.expiring`	Enviado 7 dias antes da data de vencimento de um cronograma de assinatura.
`subscription_schedule.released`	Enviado quando um cronograma de assinatura é lançado ou interrompido e dissociado da assinatura, que permanece.
`subscription_schedule.updated`	Enviado quando uma programação de assinatura é atualizada.

Testar falhas de pagamento

Use números de cartões de crédito de teste específicos para acionar falhas de pagamento de assinaturas e faturas.

Algumas atualizações de assinatura fazem a Stripe faturar a assinatura e tentar fazer o pagamento imediatamente (essa tentativa de pagamento síncrona pode ocorrer na fatura inicial ou em determinadas atualizações de fatura). Se a tentativa falhar, a assinatura é criada em um status incomplete.

Para testar o que acontece em caso de falha no pagamento de uma assinatura ativa, vincule o cartão 4000 0000 0000 0341 como forma de pagamento padrão do cliente, mas use um período de teste para diferir a tentativa (uma assinatura de alguns segundos ou minutos é suficiente). A assinatura se torna ativa imediatamente, com uma fatura preliminar criada quando o período de avaliação terminar. Leva aproximadamente uma hora para o status da fatura mudar para aberto, nesse momento ocorre a tentativa malsucedida de cobrança do pagamento.

Use clocks de teste para simular o avanço do tempo em uma área restrita, o que faz com que os recursos do Billing, como Subscriptions, alterem o estado e acionem eventos de webhook. Isso permite que você veja como sua integração gerencia uma falha de pagamento para uma renovação trimestral ou anual sem esperar um ano.

Testar pagamentos que exigem 3D Secure

Use o cartão 4000 0027 6000 3184 para simular o acionamento do 3D Secure para assinaturas e faturas.

Quando um fluxo de autenticação 3D Secure é acionado, é possível testar a autenticação ou a falha na tentativa de pagamento na caixa de autenticação 3DS que aparecer. Se o pagamento for autenticado corretamente, a fatura é paga. Se a fatura pertencer a uma assinatura com status incomplete, a assinatura fica ativa. Quando uma tentativa de pagamento falha, a tentativa de autenticação é malsucedida e a fatura permanece open.

Testar pagamentos de faturas com transferência bancária

Para testar pagamentos manuais em faturas por meio de transferências bancárias:

Em uma área restrita, crie uma fatura, defina o método de cobrança como send_invoice e defina a matriz payment_settings[payment_method_types] como [customer_balance].
Encontre a fatura no Dashboard e clique em Enviar.
Seu cliente recebeu um número de conta bancária virtual exclusivo que você pode recuperar usando a API de instruções de financiamento. Os dados bancários virtuais também estão presentes na página da fatura hospedada, assim como no PDF.

Teste a forma de pagamento padrão para faturas e assinaturas

Use IDs de cartão de teste específicos para simular formas de pagamento padrão usadas em assinaturas e faturas.

A forma de pagamento informada precisa definida como a default_payment method para ser vinculada ao cliente da assinatura ou fatura. Por exemplo, se você estiver usando pm_card_visa para criar uma forma de pagamento Visa de teste:

Chame o endpoint do PaymentMethod pm_card_visa e o cliente pretendido para a assinatura ou fatura
Com o ID da forma de pagamento resultante, crie a assinatura ou fatura com esse ID como o default_payment_method.

Agora a assinatura ou fatura cobrará esta forma de pagamento.

Saiba mais sobre como usar formas de pagamento padrão para assinaturas e faturas.

Testar verificação de ID fiscal de clientes

Use esses IDs fiscais de fantasia para acionar determinadas condições de verificação em ambientes de teste. O tipo de ID fiscal precisa ser o número de IVA da UE ou o Australian Business Number (ABN).

Número	Tipo
`000000000`	Verificação bem-sucedida
`111111111`	Verificação malsucedida
`222222222`	A verificação permanece pendente indefinidamente

Testes automatizados

Você pode configurar testes automatizados para a integração. Para otimizar os testes:

Conheça a política de retenção de dados para dados relacionados a assinaturas em uma área restrita.
Evite reutilizar recursos como Cupons e Códigos promocionais no decorrer dos testes.
Use o servidor HTTP simulado da stripe, que é baseado na API da Stripe e reflete melhor o comportamento da API.