title Payment Processing Flow type actor Customer type database "Orders DB" Customer -> Web App: click "Pay now" Web App -> Payment Service: charge card Payment Service -> Stripe: create payment intent Stripe -> Payment Service: payment confirmed Payment Service -> "Orders DB": mark order as paid Payment Service -> Web App: payment ok Web App -> Customer: show confirmation
What this diagram shows
Payment bugs are rarely about the money. They're about which system was supposed to update the order, and when. This diagram settles that argument: the payment service talks to Stripe, and the payment service marks the order paid. Nobody else.
On Braintree or Adyen instead? Rename one box.
Step-by-step flow breakdown
When to use this flow diagram
- Provider migrations. Draw the current flow, draw the proposed one, compare.
- Reconciliation debugging, when an order says paid and the ledger disagrees.
- PCI conversations. Show exactly which systems touch card data. Here it's one.
- Walking a new engineer through checkout without opening the webhook handler.
Common variations
Webhook-based confirmation
In production the confirmation usually lands async: Stripe -> Payment Service: webhook payment.succeeded.
Failed payment path
Add the sad path too: Stripe -> Payment Service: payment failed, then Payment Service -> Web App: show error.
Refunds
Run it backwards: Customer -> Web App -> Payment Service -> Stripe: issue refund.
Related flow diagram examples
Frequently asked questions
What does a payment flow diagram show?
Every system a payment touches, from the customer's click to the database update. App, payment service, Stripe, orders table.
How do I diagram my own payment flow?
Start from the click and chain the systems: Customer -> Web App -> Payment Service -> Stripe: charge card. Then add the confirmation arrows coming back.
Can I use this template for free?
Yes. Swap in your own provider and export it. No sign up.