Payment Checkout & Ledger Service  ·  View 08 of 24  ·  Structure

Platform Components (C4 Level 2)

Five planes: authorization, cardholder data, record, money operations and projections.

Editable source SVG draw.io All views
Authorization plane — stateless, latency bound Accept API gateway Envoy Idempotency key store Redis Intent service Go · state machine Route and attempt Routing engine policy vN Provider adapters one per rail Circuit breakers per provider Step-up orchestrator 3-DS · collect Cardholder data environment — PCI-DSS scope Card data Card data proxy no PAN egress Token vault format preserving Network HSM no key export Record plane — durable, append only Coupling Durable event log Kafka · 7 y Books Posting rule engine versioned Ledger poster natural key Ledger store PostgreSQL · sync repl Payment state Payment state store merchant sharded Money operations plane Resolve Callback ingest signed · deduped Outcome poller backoff State resolver legal transitions Settle File ingest re-runnable Matcher ref + amount Break manager aged Payout engine idempotent Notify Webhook dispatcher 72 h retry Replay API Projections and control Derived Balance projector rebuildable Statement service Close of books 02:00 daily Control Dual-control workflow Immutable audit Config & policy registry Card acquirer A2A rail Settlement bank Sanctions screening events post authorize · collect payout tokenise Platform Components (C4 Level 2) Interface / broker Data store Application we own Security / platform Queue / topic External / third party event / async synchronous batch Omitted: per-service sidecars, the sandbox estate and the merchant onboarding service. Nothing omitted writes the ledger. v 1.0 · owner Payments Platform Architecture · date 2026-10

Decisions

  • The cardholder data environment is its own cluster with its own HSM pair. Keeping PCI scope small is worth an extra cluster (ADR-11).
  • Payment state is sharded by merchant and every payment-path operation stays inside one shard, so there is no synchronous cross-shard transaction anywhere (ADR-08).
  • Circuit breakers sit beside the adapters and derive health from observed approval and latency, never from a provider's status page (ADR-06).

Scale

  • Authorization pods are scaled on concurrent in-flight provider calls, not request rate: at an 8-second deadline, 4,000/second means up to 32,000 outstanding calls.
  • Kafka at RF 3 with min.insync.replicas 2; ledger PostgreSQL with synchronous replication for RPO 0.

Deliberate omissions

  • Service-mesh sidecars, the sandbox estate and the merchant onboarding service. None of them writes the ledger.
  • The A2A rail edge is omitted from the drawing to keep the adapter fan legible; it is identical to the acquirer edge.
◀  Layered Architecture All views Integration Surface  ▶
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 records08-platform-components