Topic Hub

Payment architecture

Curated insights and technical field notes on Payment architecture.

Reader guide

Start with the newest decision note, then follow the topic lanes when you need payments, AI systems, or product architecture depth.

Decision notes

Clear recommendation, rejected paths, and proof trail.

Systems maps

Visual artifacts sit near the section they explain.

Source posture

Public claims stay tied to released work or cited material.

Payments

Sanctions screening as code: one policy, a different actuator per rail

The payment is final in under a second and your sanctions analyst is still opening the alert. On an instant rail there is no review window, so the screen has to clear or stop the payment in code, inside the latency budget. The policy model can be common across rails. The action on a hit cannot, because RTP, the card networks, and SEPA Instant each demand a different commit semantic.

Lead essay

Start here when you want the current Doric argument instead of a chronological archive.

Read the note

01 / Payments

Commerce architecture

Merchant-of-record decisions, checkout ownership, billing operations, settlement, reconciliation, and risk boundaries.

02 / AI tooling

Practical AI systems

Agentic commerce, multi-agent orchestration, model fine-tuning, runtime governance, and production deployment.

03 / Build notes

From idea to system

The design, architecture, and operating decisions behind Doric Stack products as they move from prototype to public release.

Latest Notes

All

May 4, 2026 By Navin Agrawal AI systems 4 min read

Most AI agents never reach production. Payments is where that gets expensive

The widely cited figure is that 88 percent of AI proofs of concept never reach production. Agentic payments inherit that gap, and the teams that cross it are not winning on model selection. They are winning on payments-specific infrastructure that makes an agent idempotent, governable, and rollback-safe at the rail boundary.

Feb 23, 2026 By Navin Agrawal Architecture 3 min read

A multi-rail exception mesh, not best-effort dedupe

A duplicate payment in production is not an edge case. It is the control plane showing you what you never modeled. A retried request can land as a final success on one rail and a settlement reject on another, look clean on the dashboard, and still move two accounts twice. Best-effort dedupe is not a control.

Feb 16, 2026 By Navin Agrawal AI systems 3 min read

AI can suggest a payment, only the control plane completes it

A payment bot did not go rogue - the architecture did. A timeout produced two valid-looking instructions for the same payout, because a downstream retry never learned the first was already in flight. Mandate-based authorization like AP2 still needs a runtime control plane with real state discipline, not policy in a config file.