Payment processing flow
From checkout through authorization, capture, and settlement.
Every e-commerce and SaaS business runs a payment flow, but the flow is almost always documented in a Stripe docs screenshot or a scattered Slack thread rather than in one authoritative diagram. This template lays out the flow in 16 nodes: the card details, validation, authorization, order creation, the capture (which is where most failures hide), success notification, and the inventory and fulfillment updates that follow.
The decision diamonds mark the fault lines — invalid card, declined authorization, failed capture — where recovery paths diverge. This template forces the question of when money actually changes hands, which is the difference between a payment system that ships and one that loses thousands to edge cases.
When to use this template
- PCI compliance reviews — auditors need to see where sensitive data enters the system, where it's processed, and where it's deleted. This diagram shows the lifecycle clearly.
- Incident postmortems — when a payment outage happens, trace which nodes failed and which recovery path should have fired.
- Subscription or refund design — start with this flow, then sketch refund or recurring-charge branches so the whole team agrees before code review.
How to adapt it
Rename the processor to your real one — Stripe, Square, Adyen — and add your domain-specific rules:
- Add a fraud check between authorization and capture, with a manual review branch for edge cases.
- Insert a loyalty or coupon calculation between the total and authorization if you apply discounts at payment time.
- Add a failed-charge retry loop before the refund path to show your subscription retry strategy (e.g. retry 3 times over 7 days, then pause).
Visual edits regenerate clean code, so you can drag nodes around and build these extensions in the editor without writing Mermaid syntax directly.
Mermaid code
Copy it anywhere Mermaid is supported — GitHub, Notion, or your docs.
flowchart TD
A[Customer initiates checkout] --> B[Collect payment method]
B --> C{Card details valid?}
C -->|No| D[Show validation error]
D --> B
C -->|Yes| E[Submit to payment processor]
E --> F{Authorization approved?}
F -->|No| G[Decline transaction]
G --> H[Show error & suggest alternatives]
H --> B
F -->|Yes| I[Create order record]
I --> J[Charge customer]
J --> K{Capture succeeded?}
K -->|No| L[Notify merchant & customer]
L --> M[Reverse authorization]
K -->|Yes| N[Send confirmation email]
N --> O[Update inventory]
O --> P[Trigger fulfillment]
Frequently asked questions
- What is a payment processing flow diagram?
- It maps the journey of a payment from when a customer enters their card details through authorization, capture, settlement, and fulfillment. It makes visible the decision points — is the card valid, is it authorized, does the capture succeed — and the recovery paths when something fails. Teams use it to design retry logic, error messaging, and customer communication.
- What is the difference between authorization and capture?
- Authorization checks that the card is valid and the customer has sufficient funds, but does not charge them yet. Capture actually takes the money. Many systems authorize immediately and capture later — sometimes days later for subscriptions. This split allows you to authorize many orders but only charge for what ships, reducing customer churn from failed charges.
- Why does this diagram include an inventory update after capture?
- Because in a real system, you do not deduct inventory when the order is placed — you deduct it when the payment succeeds. Showing this in the diagram forces teams to agree: do you reserve inventory during authorization, or only after capture? That choice affects overbooking risk and customer fairness.
- How do I adapt this for subscriptions or refunds?
- For subscriptions, add a recurring capture loop at the bottom showing the charge repeating on a schedule, with a failed-charge recovery path that retries 3–7 times before pausing the subscription. For refunds, insert a new branch after 'Fulfillment' showing the refund request, a reversal API call, and a customer credit. Visual edits regenerate clean Mermaid code, so you can sketch these extensions without touching syntax.