Payment Checkout & Ledger Service  ·  View 03 of 24  ·  People and journeys

Actors and Their Core Journeys

Six kinds of people and two machines, each with a goal in their own words.

Editable source SVG draw.io All views
People paying and being paid Buyer at checkout 12 M attempts / day peak Goal — Pay for this once, know within a second that it worked, and never see the charge twice. Core journeys Pay for an order p95 ≤ 2.5 s Approve a step-up 3-DS or UPI collect Get money back refund Merchant finance 50,000 merchants Goal — Tell me what landed in my bank account today and which orders it was for, without asking anyone. Core journeys Reconcile a payout statement Refund a customer Contest a chargeback People building against it Merchant developer the integration Goal — Get a working checkout in an afternoon, and never have to reason about a duplicate webhook. Core journeys Integrate checkout intent + webhook Replay missed events catch-up API Test a failure path sandbox People keeping it honest Platform finance ops ~40 breaks / day Goal — Close the day with the books balanced, and know the name of every rupee I cannot explain. Core journeys Close the day trial balance Clear a break dual control Release a held payout Support agent masked by default Goal — Answer 'where is my money' from the record, without being able to move any of it. Core journeys Trace one payment Raise a refund request Auditor / regulator 10-year window Goal — Reconstruct what the platform believed about this payment, and when it believed it. Core journeys Reconstruct a payment Review privileged access Machines in the cast Acquirer / rail 4 providers Goal — Receive an attempt I can process, and be believed only when I have settled it. Core journeys Answer an authorization Post a callback Deliver a settlement file Close-of-books job daily 02:00 Goal — Prove the ledger balances before anybody opens a dashboard. Core journeys Produce the trial balance Age the break account Who This Is For, and What They Get To Do Person or role Journey / task External / third party Security / platform Three journeys are mapped next: the buyer who pays, the developer who integrates, and the finance operator who closes the day. v 1.0 · owner Payments Platform Architecture · date 2026-10

What this view decides

  • The support agent can read the record and cannot move money — which is why dual control exists as a service rather than a policy (view 23).
  • Finance ops is two people against 12 M payments a day, so break resolution has to be the exception and the close has to be automatic.
  • The auditor is a first-class actor. 'Reconstruct what the platform believed, and when' is the requirement that makes the ledger append-only (ADR-02).

Assumptions

  • ~40 reconciliation breaks a day at 12 M payments — roughly 0.0003% of attempts. Below that the break desk is idle; much above it, the model does not staff.
  • The median merchant integration is written once by someone with no payments background and never revisited. That assumption sets the webhook contract (ADR-09).

Risks

  • Merchant finance is the actor most likely to be underserved: their goal is answered by statements and projections, which are the least load-bearing part of the design and the easiest to leave half-built.
◀  High-Level Architecture All views Journey — The Buyer Pays  ▶
Solution Architecture v1.0 · open source, self-hosted on Kubernetes across two in-country data centres · Payments Platform Architecture · 2026-10 · 24 views · 18 architecture decision records03-actors-and-journeys