Payment Checkout & Ledger Service  ·  View 22 of 24  ·  Assurance

Trust Zones and What Crosses Them

Six zones by decreasing exposure, and two crossings drawn in red on purpose.

Editable source SVG draw.io All views
Internet — untrusted Buyer browser Merchant server Provider callbacks Perimeter — authenticated, rate limited WAF + L7 edge API gateway mTLS to backends Credential verifier scoped keys Callback signature check 5 min freshness Application — no card data, no key material Intent service Routing engine Money operations Dashboards masked by default Cardholder data environment — PCI-DSS scope Card data proxy Token vault Network HSM no key export Record — books and evidence Ledger append only Event log Immutable audit Money egress — allowlisted only Egress proxy static IPs Acquirers Settlement bank TLS 1.3 secret key signed + nonce mTLS + scope PAN, CDE only IPsec no direct write Trust Zones and What Crosses Them External / third party Security / platform Interface / broker Application we own Data store Queue / topic synchronous failure / alternate Two crossings are drawn in red: the PAN path that bypasses the application zone entirely, and the write to the ledger that money operations may not make. Application-zone services reach the record zone only through the event log. v 1.0 · owner Payments Platform Architecture · date 2026-10

The two red crossings

  • The PAN path from the buyer's browser into the cardholder data environment bypasses the application zone entirely. That is the design, and drawing it red says so (ADR-11).
  • Money operations to the ledger is drawn red because it is a write the architecture forbids: application-zone services reach the record zone only through the event log (ADR-01).

Decisions

  • Provider callbacks are verified for signature and freshness at the perimeter — 5-minute window, nonce replay rejected — before any state is touched (ADR-05).
  • No key material and no card data exist in the application zone. A full compromise there yields tokens and the ability to attempt payments, not the ability to take money anywhere (ADR-15).
  • All money egress leaves through an allowlisted proxy on static IPs over IPsec.

Assumption

  • A merchant's secret credential will eventually leak. The design assumes it and scopes the damage: an attacker holding one can take money only into that merchant's own settlement account (ADR-15).
◀  Release and Rollout All views Identity and Access — Who May Move Money  ▶
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 records22-security-trust-zones