Payment Checkout & Ledger Service  ·  View 01 of 24  ·  Context and scope

System Context

Who uses the platform, which money networks it depends on, and the three things it is not.

Editable source SVG draw.io All views
Oversight Regulator / auditor Sanctions screening People and merchant systems Buyer Merchant server Merchant finance Platform finance ops Money networks Card acquirer Account-to-account rail Settlement bank Settlement files Payment Checkout & Ledger Service Accept · post · settle · pay out Out of scope Card issuing Lending / credit In-person terminals pays creates intent reads statements clears breaks authorize collect payout daily evidence check Payment Checkout & Ledger Service — System Context Person or role External / third party Risk / gap synchronous batch One country, one settlement currency, card-not-present and account-to-account only. The platform is not the network. v 1.0 · owner Payments Platform Architecture · date 2026-10

Decisions

  • One country, one settlement currency, multi-currency presentment only. Residency rules make a multi-country single instance a different architecture, not a bigger one.
  • Card-not-present and account-to-account only. In-person terminals bring a whole second trust model (EMV kernels, key injection, offline capture) and are excluded.
  • The platform is a payment service, not a payment network: it never clears or settles on its own rails.

Assumptions

  • 50,000 merchants, the largest 20 generating 60% of volume — so fairness between merchants is a day-one requirement, not a scale-up concern.
  • Four providers across two rails at steady state, with a fifth onboarding at any time.
  • The regulator can demand reconstruction of any payment for 10 years.

Risks

  • Every money network in the right-hand column is a system the platform cannot interrogate reliably. The entire design follows from that.
  • Issuing and lending are excluded now, and both would add held-funds licensing that reshapes the ledger's account model (ADR-13).