Agentic checkout (Stripe ACP)

Roadmap — not available to any merchant today

The ACP order-approval handler is designed in ADR-0139 (status: proposed) and its implementation slice is on an unmerged feature branch pending security review. The integration concept was explored against a Stripe sandbox auto-approve endpoint, but the production policy-evaluating handler has not been built or reviewed. No merchant has this capability enabled. This page documents the intended design; it will be updated when the implementation is complete and available.

Sill’s Transactional overview describes the signed-mandate rail, where an agent submits a signed mandate directly to Sill’s edge. The Stripe agentic-commerce rail is a second way an agent interaction reaches Sill — one Sill does not initiate. When an AI agent buys from a merchant through Stripe’s Agentic Commerce Protocol (ACP), Stripe runs the checkout and the payment; Sill is the seller-side governance hook Stripe calls before the charge, and the system of record for what happened after it.

The two rails share the parts that matter: the same policy engine decides the outcome, and every decision lands in the same signed, Merkle-chained audit envelope. What differs is the ingress and the payment mechanics — both owned by Stripe on this rail.

The three parties

A buyer asks an AI agent to purchase from a merchant. Three distinct roles are involved — and only two of them hold a Stripe account:

Party	What they are	Stripe account?
Buyer	The human (or their wallet) the agent acts for	No — just a card or wallet (Visa, Mastercard, Apple Pay, Link, …)
Agent	The AI platform that shops on the buyer’s behalf	Yes — a registered network participant with its own Stripe profile; it issues the payment token
Merchant	The seller of the goods	Yes — Stripe Connect with agentic commerce enabled; it receives the payment

Sill sits with the merchant (the seller side). It does not see the buyer’s raw card and it does not mint or redeem the payment token — Stripe does both.

How the agent pays: the Shared Payment Token

Payment on this rail uses a Shared Payment Token (SPT) — a single-use, spend-limited credential the agent creates from the buyer’s payment method for one specific purchase:

1. The buyer enters payment details in the agent’s checkout surface.
2. At submit time, the agent creates a PaymentMethod from those details and mints the SPT — POST /v1/shared_payment/issued_tokens with the buyer’s payment_method, the seller’s network_business_profile, and usage_limits (max_amount, expires_at, currency).
3. The agent presents that token to the merchant to complete the purchase. The merchant’s copy (the granted token) carries agent_details.network_business_profile (who the agent is) and the same usage_limits (what they were authorized to spend).

The token is minted right before the transaction, on the agent’s side. The merchant — and therefore Sill — never sees the underlying card, and there is no seller-side hook before the token exists. The earliest point the seller can act is the order-approval callback below.

Where Sill governs

Sill governs this rail at two moments — one before the charge, one after.

sequenceDiagram
    autonumber
    participant Agent as Agent (buyer's AI)
    participant Stripe as Stripe (agentic checkout)
    participant Sill as Sill (seller governance)
    participant Audit as Sill audit envelope

    Agent->>Stripe: Mint SPT from buyer's card, start checkout
    Stripe->>Sill: finalize_checkout (order-approval hook) ⏱ ≤4s
    Sill->>Sill: Verify signature, resolve merchant, run policy
    alt policy = approve
        Sill-->>Stripe: { manual_approval_details: approved }
        Stripe->>Stripe: Charge the SPT → merchant's account
        Sill->>Audit: Signed decision record (approved)
        Stripe->>Sill: SPT-consumed + payment events (post-charge)
        Sill->>Audit: Enrichment record — agent identity + intent + actual
    else policy = reject / escalate
        Sill-->>Stripe: { manual_approval_details: declined, reason }
        Sill->>Audit: Signed decision record (declined + reason)
    end

1 — Pre-charge: the order-approval hook. Before completing the purchase, Stripe sends a v1.delegated_checkout.finalize_checkout request to the merchant’s endpoint (Sill’s /v1/stripe/order-approval). Sill verifies the stripe-signature (HMAC), resolves the merchant from the callback’s context (the connected account) to the site’s active policy, evaluates the order, and answers approved or declined. A decline stops Stripe from charging. Every decision is written to the signed audit envelope.

2 — Post-charge: identity and intent enrichment. After the charge, Stripe emits the SPT-consumed and payment-succeeded events. Sill ingests them and writes a second, linked audit record carrying the agent’s identity (network_business_profile), the authorized spend (usage_limits), and the amount actually captured. This is where the identity and intent pillars land on this rail — at settlement, bound into the audit envelope with the decision.

The 4-second budget

The order-approval hook is synchronous: Stripe pauses the live checkout and waits for Sill’s answer, with a 4-second timeout Stripe enforces on every such call. The clock covers only that one request/response round-trip (network + Sill’s processing) — not the agent’s shopping, which happens earlier and is untimed. In practice Sill answers in well under a second.

Four seconds is generous for automated policy evaluation, but impossible for a person. This is why human-in-the-loop behaves differently on this rail:

• Reject rules → Sill declines; Stripe does not charge. (Identical to the signed-mandate rail.)
• Approve → Sill approves; Stripe charges.
• Escalate-to-human rules → there is no time to hold the checkout for a reviewer, so an escalation fails closed to a decline (reason hitl_required) rather than pausing for approval.

In short: real-time denial works exactly as everywhere else; real-time “hold for a human to approve” is not possible on a synchronous agentic checkout. See Human in the loop for how escalation works on the mandate rail.

Identity → intent → proof on this rail

Pillar	Source on the Stripe ACP rail
Identity	The agent’s network_business_profile, read from the granted SPT after the charge.
Intent	The SPT’s usage_limits (the spend ceiling the buyer authorized the agent), compared against the amount captured.
Proof	The signed, Merkle-chained audit envelope — the pre-charge decision plus the post-charge enrichment — independently verifiable against the public JWKS.

What Sill does and does not do here

• Does: verify Stripe’s signed callback, evaluate the merchant’s policy, return approve/decline within the budget, and record a signed, verifiable audit trail of the decision and the agent’s identity and authorized intent.
• Does not: mint, hold, or redeem the Shared Payment Token; touch the buyer’s card; or move money. Stripe owns token minting and the charge; Sill evaluates and signs. This keeps Sill out of PCI scope, consistent with the rest of Transactional.

Related

• Policy engine — the rule set that decides approve / escalate / reject (shared across both rails).
• Human in the loop — escalation and review (and why it differs here).
• Audit envelope and Verify a signature — the proof layer.
• Protocols — where ACP sits among the protocols at Sill’s boundary.