Bringing your Stripe objects to life with Workbench

Summary

The post demonstrates how Stripe Workbench’s Inspector can be used to examine a PaymentIntent throughout its lifecycle and diagnose payment workflow issues. It maps states including requires_payment_method, processing, requires_action, succeeded, and canceled, showing how the status property changes as inputs and decisions move the object through a state machine. The walkthrough creates and confirms test PaymentIntents with Stripe Shell commands, including a 3DS-required card that produces a requires_action state and a use_stripe_sdk next_action. It also describes reacting to state changes through webhook endpoints or Amazon EventBridge, using the Inspector to identify friction such as PaymentIntents stalled at requires_action and to debug abandoned payments.

Takeaways

1. 1

   A PaymentIntent can move through states such as requires_payment_method, requires_confirmation, requires_action, processing, requires_capture, succeeded, and canceled.

2. 2

   A 3DS-required test card produces requires_action with a next_action of use_stripe_sdk; the client-side flow uses stripe.handleCardAction(client_secret), while failed authentication returns the PaymentIntent to requires_payment_method.

3. 3

   Payment state changes can be delivered to an HTTP endpoint or Amazon EventBridge. HTTP handlers must verify the Stripe-Signature header before processing events.