MermanDraw
Open Editor

Mermaid exampleSequence Diagram

Online Card Payment Authorization Sequence Diagram

A payment sequence diagram shows the order of calls between a storefront, a payment gateway, and the card network. Backend engineers use it to agree on which system owns retries and idempotency; finance uses it to understand the gap between authorization and capture.

  • payment sequence diagram
  • card authorization flow
  • payment gateway diagram
  • checkout sequence diagram
Online Card Payment Authorization Sequence DiagramCard networkPayment gatewayStorefrontCard networkPayment gatewayStorefrontalt[Approved][Declined]Capture happens later, when the order shipsCustomerSubmit order with card detailsCreate payment (amount, currency, card token)Authorization requestApproved or declinedPayment authorizedMark order as paidOrder confirmationDecline codeAsk for another payment methodCustomer
Open in editor → 18 linesrenders in GitHub, Notion, Obsidian

Mermaid code

sequenceDiagram
    actor C as Customer
    participant S as Storefront
    participant G as Payment gateway
    participant N as Card network
    C->>S: Submit order with card details
    S->>G: Create payment (amount, currency, card token)
    G->>N: Authorization request
    N-->>G: Approved or declined
    alt Approved
        G-->>S: Payment authorized
        S->>S: Mark order as paid
        S-->>C: Order confirmation
    else Declined
        G-->>S: Decline code
        S-->>C: Ask for another payment method
    end
    Note over S,G: Capture happens later, when the order ships

Paste this into any tool that renders Mermaid, or into the editor to change the theme and export PNG or SVG. Syntax reference: Sequence Diagram guide.

What this diagram shows

The actor C as Customer line draws a stick figure instead of a box, which separates the human from the systems. The alt Approved ... else Declined ... end block holds the two outcomes side by side so the decline path is as visible as the happy path. The closing Note over S,G records that capture is a separate step, a detail that explains why a customer can see a pending charge before the order ships.

How to adapt it

  • Add a participant F as Fraud check between the storefront and the gateway if screening happens before authorization.
  • Insert a loop Retry up to 3 times around the authorization call to show how timeouts are handled.
  • Replace Card network with Bank or Wallet provider when documenting a non-card method; the shape of the flow stays the same.
  • Add activate and deactivate on the gateway to show how long the storefront waits for a response.

FAQ

Why do the replies use dashed arrows?

In Mermaid sequence diagrams -->> draws a dashed line, which is the convention for responses. Solid ->> arrows are requests. Keeping the two distinct makes a long flow readable without reading every label.

Where would a 3-D Secure challenge go in this diagram?

Between the authorization request and the network response. Add N-->>C: Challenge page and C->>N: Complete challenge inside an opt 3DS required block so it is clear the step does not always happen.