Skip to Content
Payment RailsOverview

Payment Rails

Keel is the decision and evidence substrate beneath agent-driven payments. A payment rail is a protocol or network through which an AI agent can move money on a user’s behalf. Across nine rails today, Keel uses one consistent model: decide before the agent acts, execute or witness the action, and produce cryptographically verifiable evidence afterward.

The substrate is rail-agnostic by design. Whether your agent settles via Stripe MPP, USDC on Base via x402, or any of the other seven supported rails, the permit shape, decision flow, and audit evidence are identical.

The two rungs of a Keel payment rail

Each payment rail can support two layers of Keel integration:

RungWhat it meansWhen to use
EvidenceKeel binds the rail’s payment artifacts (challenges, payloads, receipts) into a signed permit. The agent or your app executes the payment; Keel records and verifies the result.When the agent already knows how to talk to the rail and you want decision authority + tamper-evident audit
RuntimeKeel drives the rail directly — issues the challenge, presents credentials, captures the receipt — through the managed-path dispatcher. Your app calls POST /v1/execute with the spend intent and Keel handles the wire protocol.When you want the simplest integration surface and want Keel as the dispatch authority

The evidence rung is mandatory for any rail Keel supports. The runtime rung is built when the rail has stable wire semantics and customer demand justifies it.

Status matrix (2026-06-09)

RailEvidence rungRuntime rungDeep guide
Stripe MPP✅ Shipped✅ Shipped✅ Stripe MPP
x402✅ Shipped✅ Shipped✅ x402
AP2 (Google Agent Payments Protocol)✅ Shipped——
PayPal✅ Shipped——
Visa Intelligent Commerce✅ Shipped——
Mastercard✅ Shipped——
OpenAI ACP✅ Shipped——
L402✅ Shipped—✅ L402
UCP (Google Universal Commerce Protocol)✅ Shipped——
Amex ACE✅ Scaffold——

Evidence-only rails accept tamper-bound rail evidence under resource_attributes_json.<rail> on any v6 permit. The runtime rung opens when the rail has both a stable public wire spec and customer signal — runtime is demand-gated, not capability-gated.

The Amex ACE Dev Kit shipped April 2026 but its wire specs are NDA-gated. Keel’s Amex ACE rail is a scaffold today; the evidence layer is built and tested, but no real settlement runs through it until Keel and a customer complete Amex NDA + onboarding.

How the substrate works

Every payment-rail integration rides the same substrate:

  1. Permit issuance — POST /v1/execute (or an agent SDK call) carries an action_verb like mpp.payment, the rail’s evidence payload, and the requested spend authority. Keel evaluates policy and issues a permit binding the request.
  2. Tamper-evident binding — the permit’s signed binding hash recursively covers the entire resource_attributes_json mapping, including any rail evidence stored at resource_attributes_json.<rail>. Any post-issuance change to the rail evidence is detectable on verification.
  3. Runtime execution (rails with the runtime rung) — Keel’s managed-path dispatcher presents credentials, handles the rail’s challenge/response, captures the receipt, and binds it into provider_attestation.
  4. Audit + verification — the signed permit + receipt + binding hash can be independently verified offline using keel-verifier (PyPI 3.3.0+) or any RFC 8785 implementation in any language.

See Independent Verification for the full verification story and Substrate v6 binding for the rail-evidence binding details.

Per-rail summary

Stripe MPP

Stripe’s Machine Payments Protocol for agent-driven purchases. Keel handles decision authority on top of customer-owned Stripe Link credentials, then drives the merchant interaction through the managed-path dispatcher and binds the merchant receipt into provider attestation.

Status: evidence + runtime. Deep guide: Stripe MPP.

x402

Open HTTP-native payments protocol from x402-foundation. Built around the HTTP 402 Payment Required status code — the resource server challenges, the client pays (typically USDC on Base or another EVM network), the server returns the resource plus a settlement receipt. Keel’s runtime drives the full challenge → pay → receipt → bind sequence under one permit.

Status: evidence + runtime. Deep guide: x402.

AP2 (Google Agent Payments Protocol)

Verifiable-credential-based agent payment protocol from Google. Agents present Intent / Cart / Payment VCs signed via Ed25519 to merchants; merchants verify the VC chain before fulfillment.

Status: evidence rung only. Bind the VC chain at resource_attributes_json.ap2 on any v6 permit; the substrate-v6 binding hash makes it tamper-evident.

PayPal

PayPal’s Agentic Toolkit — agent-driven PayPal payments through Orders V2 and related surfaces.

Status: evidence rung only. Runtime path is the closest “buildable-now self-serve” rail outside Stripe MPP and x402, gated on customer signal.

Visa Intelligent Commerce

Visa’s Acceptance APIs and Trusted Agent Protocol (TAP) suite for agentic commerce.

Status: evidence rung only. Production runtime requires a signed Visa partner agreement; sandbox can be unblocked sooner.

Mastercard

Mastercard Agent Pay (the rail) and the Developer Agent Toolkit (MCP-based API discovery).

Status: evidence rung only. Runtime is certified-processor-only, gated behind Mastercard partnership.

OpenAI ACP

OpenAI Agentic Commerce Protocol — agent payments via the OpenAI runtime, often composed with Stripe Shared Payment Token.

Status: evidence rung only. Buildable-now self-serve on the seller / delegated side, gated on customer signal.

L402

Lightning Network HTTP 402 — Bitcoin Lightning payments behind the HTTP 402 status code. Macaroon-based authentication, BOLT 11 invoices, preimage-as-proof settlement.

Status: evidence rung. Deep guide: L402. Zero-gatekeeper, self-hostable rail. Highest-leverage demand-gated runtime to build because no partner approval is required.

UCP (Google Universal Commerce Protocol)

Google’s Universal Commerce Protocol covering payments through the Google Pay handler.

Status: evidence rung only. Runtime gated on Google Pay handler onboarding.

Amex ACE

American Express Agentic Commerce Experience — Amex’s agentic commerce framework with the ACE Dev Kit (5 services, 3 spec’d, OAuth + mTLS).

Status: evidence rung is a scaffold (no public wire spec). Runtime gated on Amex NDA + onboarding.

What you can rely on

  • One model, every rail. Permit shape, action verb, spend authority, signed binding, and independent verification are identical across all nine rails.
  • Rail evidence is tamper-evident. Substrate-v6 covers nested rail evidence in the signed permit binding hash, on every v6 permit, without rail-specific binding fields.
  • No raw rail credentials in Keel evidence. Keel binds rail receipts and identifiers, never raw secrets, raw card numbers, or private keys.
  • Forward-only canonical. v6 uses RFC 8785 (JSON Canonicalization Scheme) for the rail-evidence binding hash, verifiable from first principles in any language with an RFC 8785 implementation.
Last updated on Edit this page on GitHub 
Realtime VoiceStripe MPP