Payment Checkout & Ledger Service  ·  View 13 of 24  ·  Runtime

Authorize, Acknowledge, Post

Seventeen messages, and the gap between message 14 and message 17 that defines the architecture.

Editable source SVG draw.io All views
Buyer API gateway Intent service Token vault / HSM Provider adapter Acquirer Event log Ledger 1. POST /intents + key 2. authenticated create 3. key seen? return original 4. intent.created 5. client secret 6. card details (CDE only) 7. network token 8. route: policy v7 9. authorize(token) 10. auth request · 8 s deadline 11. approved + ref 12. result=approved 13. payment.authorized 14. succeeded 15. post txn (event_id key) 16. entries sum to zero 17. ledger.posted Critical Flow — Authorize, Acknowledge, Post The buyer is answered at message 14; the books move at 15-17. That gap is the architecture, and it is what the resolver and matcher exist to close. v 1.0 · owner Payments Platform Architecture · date 2026-10

The window

  • The buyer is answered at message 14. The books move at 15–17. In between, a payment has succeeded in the world and is not yet in the ledger (ADR-01).
  • Posting synchronously inside the request would close the window and make a ledger partition into a checkout outage. At 4,000/second during a sale, that is the more expensive failure.

Decisions

  • Card details go from the buyer's browser to the cardholder data environment directly, never through the application zone (ADR-11).
  • The routing decision is taken and recorded before the provider call, with the policy version stored on the attempt (ADR-06).
  • The ledger checks that entries sum to zero before appending. An unbalanced transaction is rejected, not corrected later (ADR-02).

Numbers

  • Provider deadline 8 s hard, p95 total buyer-visible confirm ≤ 2.5 s.
  • Ledger posting p99 ≤ 2 s after a terminal event — the stated width of the window.
  • Balance visible to the merchant within 30 s of posting.