Payment Processing Sequence Diagram

Q: How does a Stripe payment flow work in sequence?

A Stripe payment flow starts with the customer clicking Pay, your server creating a payment intent via the Stripe API, the customer entering card details on a Stripe-hosted form, Stripe sending a webhook (payment.succeeded) to your server, and your server updating the order status in your database.

Q: What is a payment sequence diagram used for?

A payment sequence diagram is used to document the exact order of messages between customer, web app, payment API, payment provider, and database during a checkout flow. It helps teams understand webhook timing, implement idempotency, and debug payment failures.

Q: Can I edit this payment processing diagram?

Yes. Click Open in Editor to load this diagram into SeqDiagram.com. You can modify it for your own payment provider (Stripe, PayPal, Braintree, etc.) and export as PNG, SVG, or Mermaid — free, no account required.

Diagram Source — edit it live in the browser

title Payment Processing Flow

actor Customer
participant "Web App" as App
participant "Payment API" as Pay
participant "Stripe" as Stripe
participant Database

Customer->App: Click "Pay now"
App->Pay: POST /charge
Pay->Stripe: Create payment intent
Stripe-->Pay: Payment intent ID
Pay-->App: Redirect to Stripe
App-->Customer: Show payment form
Customer->Stripe: Enter card details
Stripe->Pay: Webhook: payment.succeeded
Pay->Database: UPDATE order status = paid
Pay-->App: 200 OK
App-->Customer: Show confirmation

What this diagram shows

This sequence diagram covers the modern Stripe Checkout / Payment Intents pattern used by most e-commerce and SaaS applications. It maps the complete payment lifecycle across five participants: customer, web app, internal payment API, Stripe, and database.

The key insight this diagram makes visible: card details never touch your server. The customer enters them directly on a Stripe-hosted form. Your app only learns the payment succeeded when Stripe sends a webhook — which means your order-fulfilment logic lives inside a webhook handler, not the checkout response.

Step-by-step flow breakdown

Customer clicks PayThe checkout button triggers a request to your backend to initiate the payment.

Backend creates a Payment IntentYour Payment API calls Stripe's POST /v1/payment_intents with the amount, currency, and metadata. Stripe returns a client_secret.

Customer sees Stripe's payment formThe browser is redirected to Stripe Checkout (or Stripe Elements is initialised with the client secret), displaying a PCI-compliant card input.

Customer enters card detailsCard data goes directly to Stripe — it never passes through your servers, so you avoid PCI DSS scope for cardholder data.

Stripe fires a webhookOn payment success, Stripe POSTs a payment_intent.succeeded event to your webhook endpoint. This is the authoritative signal that money moved.

Order status updated in databaseYour webhook handler updates the order to paid, triggers fulfilment (send email, provision access, ship item), and returns a 200 to Stripe.

Customer sees confirmationThe app redirects the customer to a success page (polled or real-time via WebSocket), showing the order confirmation.

When to use a payment sequence diagram

Checkout implementation docs — show frontend devs exactly when to call your backend vs. when to talk to Stripe directly
Security review — prove that card data never flows through your server
Webhook design — document which events trigger which business logic and in what order
Idempotency planning — trace the flow to identify where duplicate events could cause double-fulfilment
Incident review — replay a failed payment sequence to find where the flow broke

Common variations

Subscription / recurring billing

Add a Stripe->Pay: Webhook: invoice.payment_succeeded step on a recurring schedule. Your handler renews the subscription in the database rather than marking an order paid.

Refund flow

Add a separate flow starting with Customer->App: Request refund, App->Stripe: POST /v1/refunds, and a charge.refunded webhook updating the order to refunded.

PayPal or other providers

Replace the Stripe participant with your payment provider. The webhook-confirmation pattern is the same across Stripe, Braintree, PayPal, and most modern PSPs.

Payment failure handling

Add an alt fragment: [success] running the happy path and [failure] showing payment_intent.payment_failed triggering a retry email.

Related sequence diagram examples

Frequently asked questions

How does a Stripe payment flow work in sequence?

Your server creates a payment intent → customer enters card details on Stripe's form → Stripe charges the card → Stripe fires a payment_intent.succeeded webhook to your server → your server updates the order. Card data never touches your server.

What is a payment sequence diagram used for?

It documents the exact order of messages during checkout — useful for implementation docs, security reviews, webhook design, and debugging payment failures in production.

Can I edit this payment processing diagram?

Yes — click Open in Editor above. Modify participants, add your own services, adapt to PayPal or another provider, then export as PNG, SVG, or Mermaid. Free, no account needed.

Why does the webhook come before the frontend confirmation?

Webhooks are the authoritative payment signal — they arrive asynchronously from Stripe after the card is charged. The frontend shouldn't assume payment succeeded based on the checkout redirect alone; it should wait for the webhook to update order state, then display confirmation.