Agentic Commerce Protocol 2026-04-17: what merchant and PSP integrations now have to test

What the 2026-04-17 release changed

The Agentic Commerce Protocol (ACP) is an Apache 2.0 specification whose repository names OpenAI and Stripe as founding maintainers and labels its status "Beta". It defines two surfaces a merchant or its payment service provider (PSP) implements: an Agentic Checkout REST API that an agent calls to create, update, complete, and cancel a checkout session, and a Delegate Payment endpoint that turns a card credential into a vault token the merchant's PSP can charge. Versions carry dates. The repository lists 2025-09-29, 2025-12-12, 2026-01-16, 2026-01-30, and 2026-04-17; we checked the spec/ folder on 2026-09-22 and 2026-04-17 is still the latest release, with later changes held in unreleased/.

The 2026-04-17 changelog marks 2026-01-30 as deprecated and carries three changes that alter test scope:

• Idempotency became mandatory. The Idempotency-Key header changed "from required: false to required: true on both Agentic Checkout and Delegate Payment APIs", with a 255-character limit and UUID v4 recommended. Missing keys return 400 idempotency_key_required, a key still in flight returns 409 idempotency_in_flight with Retry-After, and a reused key with a different body returns 422 idempotency_conflict. Replays carry Idempotent-Replayed: true.
• Webhook signing got a fixed format. The Merchant-Signature header is t=<unix_seconds>,v1=<64_hex>, an HMAC-SHA256 over timestamp + "." + raw_body, with a recommended tolerance of 300 seconds.
• Orders gained money fields. The order schema added adjustments[] for "refunds, credits, returns, disputes, chargebacks", an amount_refunded total type, and the webhook payload dropped the legacy refunds[] field.

The clearest dated change is the session state machine. The 2025-09-29 checkout OpenAPI defined five session statuses: not_ready_for_payment, ready_for_payment, completed, canceled, and in_progress. The 2026-04-17 checkout OpenAPI defines eleven, adding incomplete, requires_escalation, authentication_required, pending_approval, complete_in_progress, and expired. A test suite written against the first release covers fewer than half of the states a 2026-04-17 server can return.

The card networks describe their own agent programmes in dated press releases. Visa's release of 8 April 2026 says Visa Intelligent Commerce Connect "enables merchants to accept payments initiated via major agent protocols including: Trusted Agent Protocol, Machine Payments Protocol (MPP), Agentic Commerce Protocol (ACP), and Universal Commerce Protocol (UCP)", and that it is in pilot with named partners and "rolling out to more partners this year". Mastercard's release of 10 September 2025 stated: "By the holiday season, all U.S. Mastercard cardholders will be enabled for the Mastercard Agent Pay program, with global rollout to follow shortly thereafter." We cite both as the networks' own statements; neither release gives transaction volumes.

Why ACP changes the test surface for a merchant or PSP

The Delegate Payment RFC states that "Payments, settlement, and compliance remain on the merchant's rails." The agent does not authorise or capture; the merchant's PSP does. The agent asks the Delegate Payment endpoint for a token, and the token "MUST ONLY be usable within the provided Allowance (reason, max_amount, currency, expiry)" and "MUST become invalid at or after allowance.expires_at". In 2026-04-17 the allowance reason has one allowed value, one_time, and max_amount is an integer in minor units. The money control is therefore the PSP's enforcement of that allowance at authorisation time. A PSP that accepts a charge above max_amount, in another currency, for another merchant_id, or after expiry has issued a token that behaves like a stored card.

The request body carries a full card number and CVC, so the endpoint handles cardholder data and sits inside the PSP's PCI DSS scope. The RFC requires that "logs MUST NOT contain full PAN or CVC". A log line from a failed tokenisation call is a place that rule breaks.

A PSP that already supports idempotency keys on its own API still has to check them against the ACP wording. Both ACP RFCs require keys to be scoped to "authenticated identity + endpoint path", require the original response "with the same HTTP status code" on replay, forbid caching 5xx responses, and require key mappings for "at least 24 hours". The delegate payment RFC also states that null and an absent key are different bodies, while 1.0 and 1 are equal and array order matters. An agent that retries a complete call after a timeout relies on exactly these rules to avoid a second order and a second authorisation.

State handling carries money too. The checkout RFC requires a server to return 405 on cancel when the session is already completed or canceled, and requires complete without authentication_result on an authentication_required session to fail with code requires_3ds. A server that lets a cancel succeed after completion leaves an order and an authorisation the agent believes are void.

What we test in an ACP integration

This is our test list for a merchant or PSP implementing ACP 2026-04-17. It is our practice; the specification does not prescribe it. General idempotency and webhook procedure is on our payment idempotency testing guide and the API and webhook testing service page, so the list covers only what ACP adds.

The baseline request uses synthetic identifiers and the specification's own test card number. From 2026-04-17, risk_signals may be an empty array.

POST /agentic_commerce/delegate_payment HTTP/1.1
Host: psp.sandbox.example.test
Authorization: Bearer test_synthetic_key
Content-Type: application/json
API-Version: 2026-04-17
Idempotency-Key: 6f1c2a9e-4b7d-4e21-9a55-0c3e8d7b1f42

{
  "payment_method": {
    "type": "card",
    "card_number_type": "fpan",
    "number": "4242424242424242",
    "exp_month": "11",
    "exp_year": "2027",
    "display_card_funding_type": "credit",
    "metadata": {}
  },
  "allowance": {
    "reason": "one_time",
    "max_amount": 4599,
    "currency": "eur",
    "checkout_session_id": "cs_synthetic_0001",
    "merchant_id": "merchant_synthetic_01",
    "expires_at": "2026-05-12T10:30:00Z"
  },
  "risk_signals": [],
  "metadata": {}
}

For the checkout API we walk every transition into and out of the eleven statuses, and we assert three rules the RFC states outright: cancel on completed or canceled returns 405, complete on authentication_required without authentication_result fails with requires_3ds, and a successful complete returns status: completed with an order. The 3-D Secure outcomes feed into our 3DS2 challenge flow tests, since ACP added frictionless and denied authentication examples in this release.

Order webhooks run in the other direction: the webhook spec describes a receiver hosted by OpenAI, and the merchant signs and sends. The receiver will "Reject with 401 if missing, malformed, timestamp out of window, or verification fails." We capture each outgoing event, recompute the HMAC over the timestamp and raw body, and assert a match. We then force the first delivery to fail and hold the retry for more than 300 seconds. A sender that replays the stored request with its original t value fails the recommended window; each retry has to be signed again with a new timestamp. This is our reading of the recommended tolerance; the spec does not describe sender retries.

The same capture checks the money fields. We post a partial refund and assert that adjustments[] and the amount_refunded total match the ledger entry in minor units, because the payload "MUST contain the full Order object (not incremental deltas)". A merchant that sends only the changed fields leaves the agent showing the buyer the wrong refund.

We run every case in the PSP sandbox with synthetic identifiers and published test card numbers. On acquiring platforms, the allowance cases above are the ones that decide whether a delegated token can be charged beyond what the buyer approved.