Um payload só não testa o fluxo inteiro
Testar com um único evento payment_intent.succeeded valida se seu handler processa aquele formato — mas não testa se seu sistema trata corretamente a sequência de eventos que um pagamento real dispara: criação, processamento, e só depois sucesso (ou falha). Veja a referência de endpoints e payload do Stripe se você só precisa de um exemplo estático.
Modelando o ciclo de vida com Response Sequences
Configure uma Mock Rule com Response Sequences pra que cada chamada ao seu endpoint de recebimento devolva o próximo evento da sequência:
// Mock Rule: POST / → Response Sequences, mode: last
[
{ "status": 200, "body": "{\"id\":\"evt_1\",\"type\":\"payment_intent.created\",\"data\":{\"object\":{\"id\":\"pi_1\",\"status\":\"requires_payment_method\"}}}" },
{ "status": 200, "body": "{\"id\":\"evt_2\",\"type\":\"payment_intent.processing\",\"data\":{\"object\":{\"id\":\"pi_1\",\"status\":\"processing\"}}}" },
{ "status": 200, "body": "{\"id\":\"evt_3\",\"type\":\"payment_intent.succeeded\",\"data\":{\"object\":{\"id\":\"pi_1\",\"status\":\"succeeded\"}}}" }
]Chame o mesmo endpoint 3 vezes seguidas (ou use o botão Replay do dashboard) e seu handler recebe a sequência completa, um evento por chamada — exatamente como testaria uma máquina de estados de pedido.
E a assinatura stripe-signature?
stripe-signature criptograficamente válido a partir do mock. Isso significa que a etapa de validação de assinatura do seu webhook handler precisa ser testada separadamente (ex.: bypassada por uma flag de ambiente de teste, ou testada com um payload+secret de teste gerado pela própria lib do Stripe). O httpdrop simula o payload e a sequência de eventos, não a criptografia da entrega.Na prática, isso não é um problema pro que a maioria dos times testa no dia a dia: a lógica de negócio que reage a cada tipo de evento. A assinatura é testada uma vez, isoladamente, com as ferramentas do próprio Stripe (stripe listen/stripe trigger da Stripe CLI).