Authorizations and charges

Authorization

What a payer authorized, created when a rail verifies a proof.

• single — an x402 payment or an MPP charge. At most one charge that was not released. If the handler failed and the charge was released, the same proof can be presented again.
• reusable — an L402 credential, a KYAPay token, an MPP session, or a credit account. Many charges until the limit is consumed or the authorization expires.

Authorizations are keyed by rail and proof, so presenting the same proof finds the same authorization. That is replay protection for single-use proofs and reuse for reusable ones.

Charge

One economic effect against an authorization, tracked on two independent axes.

payment      reserved ──► settling ──► settled ──► refund_pending ──► refunded
                │             │  ▲                      │
                ▼             ▼  │                      ▼
             released      unknown ◄────────────────────┘   resolved by lookup
                              │
                              ▼
                           failed

fulfillment  pending ──► running ──► completed
                            │
                            ▼
                          failed

• Creating a charge reserves its amount on the authorization atomically. Settling commits it; releasing returns it.
• Every provider call is preceded by a write (settling, refund_pending) and followed by one.
• A timeout or ambiguous answer becomes unknown and is resolved only by asking the provider.
• The payment axis says whether money moved; the fulfillment axis says whether the service exists. Reconciliation uses both.

A paid call, step by step