How to build agentic payments without building a liability machine

1. Pick one economic action

Start with a narrow action such as paying for a single API request, replenishing an approved SKU, booking a refundable itinerary under a limit, or settling a known invoice. Define the buyer, seller, asset, rail, value range, cadence, delivery event, and recourse.

Do not begin with “the agent can buy anything.” Broad autonomy hides missing policy until the first incident.

2. Model intent, order, decision, payment, and outcome

Create typed internal objects before adopting external schemas. The intent preserves purpose and constraints. The order freezes the seller’s economic terms. The decision records versioned policy. The payment records rail state. The outcome records fulfillment and remediation.

Use stable identifiers to connect them and append events rather than mutating the historical story. External protocol artifacts can be stored or referenced alongside the internal record.

3. Put policy and signing outside the model runtime

The agent proposes a transaction. A deterministic policy engine evaluates it. A credential service signs or grants authority only when the approved decision and exact transaction match. This separation contains prompt injection and model error.

• Validate merchant, destination, amount, currency, asset, network, purpose, and expiry.
• Use transaction-scoped or seller-scoped credentials whenever possible.
• Require step-up for changed terms, new merchants, risky categories, or irreversibility.
• Keep revocation and emergency freeze independent of the agent.

4. Add one payment adapter and make retries boring

Choose the rail that fits the actual use case. Cards may be strongest for consumer acceptance and recourse. Stablecoin and HTTP-native flows may fit paid APIs and machine services. Bank rails may fit invoices or account-to-account use cases.

Every financial request carries a stable idempotency key and order hash. Timeouts lead to status verification, not a fresh payment. Webhooks are authenticated and idempotent. Reconciliation can repair lost responses without duplicating value movement.

5. Make the receipt explain the decision

A useful receipt shows the principal, agent, seller, items or resource, total, currency or asset, policy basis, payment status, fulfillment state, and recourse. It links the original intent and final order without exposing secrets.

Operators need the same joined view with protocol versions, signature verification, request hashes, error details, and reconciliation events.

6. Test the failures that create money bugs

Write fixtures for changed carts, stale mandates, replayed signatures, duplicate webhooks, lost settlement responses, insufficient funds, unsupported networks, merchant timeouts, partial fulfillment, and refund failure. Run the same fixtures against every payment adapter.

7. Launch with ceilings and an exit

Use low transaction and daily ceilings, restricted merchants, explicit rollout cohorts, real-time anomaly monitoring, and a kill switch. Review sampled decisions and every exception. Increase autonomy only when evidence shows the controls and recovery paths work.

A launch is successful when the organization can detect, explain, contain, and remediate unexpected behavior—not merely when payment conversion increases.