Architecture

The design bet behind PAID: if every financial event is deterministic, idempotent, and cryptographically chained, then audit, reconciliation, and dispute defense stop being projects and become queries.

The payment flow

payment intent
  → five-stage router          (context → jurisdiction → filter → ruleset → cost)
  → execution plan             (one rail, one provider)
  → authorize → capture        (idempotent; refund / cancel symmetric)
  → ledger event               (Ed25519-signed, hash-chained to the previous event)
  → reconciliation             (reads the chain; discrepancies surface, never smoothed)
  → settlement                 (per connected rail — incl. card → USDC instant settlement)

The ledger is the system of record

Every financial event — success or failure — is chained to the previous event and signed with PAID's key. Anyone holding the published public key can verify the entire history offline; tampering is mathematically detectable. Reconciliation reads this chain rather than diffing exports, which is why it takes seconds instead of days. Full detail: the hash-chained ledger.

Design guarantees

• Deterministic, not heuristic. Same inputs produce the same routing decision and the same ledger state. Where truth is computable, PAID computes it — no probabilistic shortcuts in the money path.
• Idempotent mutations. Every mutating call is retryable without double effects — the retry problem is solved at the API contract, not left to integrators.
• Fail-closed. When a provider or a key is unavailable, the affected path refuses rather than pretending. Onboarding refuses in production rather than fabricating an enrollment it cannot complete.
• No silent correction. Discrepancies are surfaced as discrepancies. A ledger that silently "fixes" itself is a ledger an auditor cannot trust.
• No hidden concurrency in decisions. The router is synchronous by design — resilience lives in multi-rail structure, not in background retry loops.

What sits where

• Routing — the five-stage sequencer: intelligent routing
• Providers — adapters behind the four-part gap model: multi-PSP · integrations
• Agent surface — quote-first MCP tools: agentic commerce
• API — intents, captures, refunds, transfers, ledger events, reconciliation reports: API reference

Related

• Payment orchestration — the pillar overview
• Security model · Developer docs