Agentic Rails Atlasby merces.ai

Persona

PSP or acquirer product lead

Tokens, routing, risk, fees, and support for many protocols at once.

Verified (verified under 30 days ago)

Role

Goals

  • Offer merchants one integration that accepts agent orders from ACP, UCP, TAP and MPP.
  • Issue and vault scoped payment tokens (SPTs, vault tokens, network agentic tokens) with usage limits.
  • Route agent transactions through the right network token (VIC or Agent Pay) and pass agent indicators in the authorization message.
  • Keep fraud and dispute rates flat as agent volume grows.
  • Price agent transactions without new interchange surprises.
  • Host Delegate Payment and similar endpoints so merchants never touch raw card data.

Pains

  • The protocol count keeps growing and each one has dated versions, so the integration surface is never finished.
  • Agent indicators are not reliably present in authorization messages, so issuers cannot distinguish agent traffic and decline rates are unpredictable.
  • SPTs and vault tokens are products, not standards, and competitors run their own, so merchants ask for all of them.
  • No network rule yet shifts liability for agent purchases, so the acquirer absorbs disputes.
  • Stablecoin rails (x402, MPP on Tempo) bypass the acquirer entirely for small payments.
  • Idempotency and replay rules differ by protocol (Idempotency-Key, challenge id, nonce), and bugs here create duplicate charges.

Decisions they own

  • Which protocols to support in the agentic commerce product and which to leave to partners.
  • Token scope defaults: amount, currency, expiry, single-use or reusable.
  • Risk thresholds for agent-initiated transactions and when to require 3DS2.
  • Whether to run an x402 or MPP facilitator alongside card processing.
  • How to report agent orders to merchants and issuers.

Vocabulary

  • Shared Payment Token
  • vault token
  • network token
  • authorization
  • routing
  • interchange
  • 3DS2
  • Delegate Payment
  • idempotency
  • dispute
  • settlement
  • acquirer
  • agent indicator
  • PCI DSS

Each protocol from this seat

Relevance levels: High, a main persona on the protocol page; Medium, owns, implements or verifies a step; Low, relies on or observes a step; None, no role found in the protocol page.

ERC-8004: Trustless Agents

Relevance: None

Not one of the main personas on the ERC-8004: Trustless Agents page. The responsibility table gives this persona no step.

x402

Relevance: None

Not one of the main personas on the x402 page. The responsibility table gives this persona no step.

Visa Trusted Agent Protocol

Relevance: None

Not one of the main personas on the Visa Trusted Agent Protocol page. The responsibility table gives this persona no step.

Agentic Commerce Protocol (ACP)

Relevance: High

Hosts Delegate Payment or a compatible token product (Stripe SPT), vaults the card, enforces the allowance and processes the merchant charge. Source [1, 2, 3]

Goals

  • Issue tokens that only work inside the allowance
  • Keep merchants out of PCI DSS scope
  • Offer agentic payments to existing merchants

Pains

  • ACP defines no error codes for allowance violations
  • Signing rules for Delegate Payment contradict each other
  • Network token support varies

Implements

  • POST /agentic_commerce/delegate_payment returning vt_ tokens
  • Allowance checks at charge time
  • Risk signals such as card_testing scores

Must trust

  • The agent to set max_amount to what the buyer approved
  • The agent's bearer key and signature handling

Questions they ask

  • Do we require the detached Signature even though the OpenAPI marks it optional?
  • Which decline code do we return for an expired token?
  • Can network agent tokens sit under our token?

First three steps

  1. Implement the Delegate Payment schema with all six allowance fields
  2. Decide and publish your signature policy
  3. Map allowance failures to clear decline codes

Metrics they care about

  • Token issuance volume
  • Declines by allowance rule
  • Fraud rate on delegated tokens

A day in the life. Marco works on a PSP's agentic team. His service receives Delegate Payment calls from an agent platform: a network token, an allowance of 120 dollars for one merchant and one checkout session, expiring in thirty minutes. He returns a vault token and stores the limits next to it. An hour later the merchant tries to charge it for 140 dollars after adding gift wrap without a new confirmation. His engine declines it, but ACP gives him no standard code, so he documents his own and tells the merchant to start a new session. He also requires the detached signature on every request, since RFC section 2.2 says the client must sign.

Steps in the responsibility table

  • VerifiesSet the allowance (max_amount, merchant, session, expiry)
  • OwnsIssue and vault the token
  • VerifiesCharge the token inside the allowance
  • ImplementsHandle refunds and chargebacks

UCP

Relevance: High

The business's payment service provider: receives the token from the business, authorizes and settles, and may publish its own UCP handler. Source [4, 5, 6, 7, 8]

Goals

  • Process agent-originated tokens like any other card-not-present payment
  • Offer merchants a ready UCP handler
  • Support 3DS2 through UCP actions

Pains

  • Token formats differ by handler
  • No dispute rules specific to agent transactions
  • 3DS state lives with the PSP, while the challenge surface lives with the platform

Implements

  • Token processing for Google and other handlers
  • A tokenization handler (Adyen) or a payments handler (Stripe)
  • Payment mandate verification if AP2 is used

Must trust

  • The business to forward tokens unchanged
  • The credential provider's token binding
  • Platforms to render 3DS challenges correctly

Questions they ask

  • Which handler do our merchants advertise?
  • How do we map UCP actions to our 3DS flow?
  • Who carries the loss when an agent misreads the buyer?

First three steps

  1. Document which UCP handlers you can process
  2. Publish a handler or tokenization guide
  3. Map the authentication extension's actions to your 3DS server

Metrics they care about

  • Authorization rate for UCP-originated tokens
  • 3DS challenge completion rate
  • Dispute rate on agent orders

A day in the life. Jonas manages agentic payments at a PSP. Merchants ask whether his platform can take tokens from UCP checkouts on Google, and the answer has to be yes, because the merchant's PSP must process Google's tokens. His team also publishes a tokenization handler that returns a token tied to the checkout session and merchant. When v2026-08-25 adds 3DS2 through actions, he maps device data collection and challenge to his existing 3DS server. UCP never carries the EMV messages, so his state machine stays where it was. Disputes still follow card rules, which he finds both reassuring and incomplete.

Steps in the responsibility table

  • ObservesWrite the payment handler spec
  • VerifiesIssue the opaque token
  • OwnsAuthorize and settle the token
  • VerifiesSign the checkout and verify the AP2 mandate
  • ImplementsHandle refunds and disputes

Stripe MPP (Machine Payments Protocol)

Relevance: High

Settles MPP charges on card and fiat rails: Stripe for the stripe method, or a Client or Server Enabler for the Visa card method. Source [9, 10, 11, 12]

Goals

  • Bring existing card and wallet acceptance to machine clients
  • Keep raw card data out of client and server scope
  • Reuse fraud, tax, refunds and reporting

Pains

  • Replayed SPT credentials (CVE-2026-34210)
  • Mapping one challenge to one PaymentIntent or authorization
  • No published SPT pricing

Implements

  • PaymentIntent creation with confirm true and an idempotency key from challenge id and SPT
  • JWE decryption and network authorization as Server Enabler
  • Network token and cryptogram provisioning as Client Enabler

Must trust

  • The merchant server to validate the challenge before charging
  • The card network for authorization and dispute rules
  • The Client Enabler key handling

Questions they ask

  • Is this payment card-not-present with agent involvement, and how do disputes work?
  • What metadata ties a PaymentIntent to its challenge?
  • Do stablecoin charges carry a percentage fee?

First three steps

  1. Read draft-stripe-charge-00 and draft-card-charge-00
  2. Run the mppx stripe example in test mode
  3. Map PaymentIntent and authorization references into receipts

Metrics they care about

  • Authorization rate on agent traffic
  • Dispute rate by method
  • Duplicate charge incidents

A day in the life. Lena works on acceptance at a payment processor that already serves Visa merchants. Visa's card method lets her team act as a Server Enabler: merchant servers forward an encrypted token they cannot read, her service decrypts it and asks the network for authorization. Card economics and chargebacks stay as they are. On the first week a merchant's buggy client sends the same credential twice; her idempotency checks return the first authorization instead of charging again. She reports authorization rates for agent traffic separately, because nobody yet knows whether it behaves like ordinary card-not-present volume.

Steps in the responsibility table

  • ImplementsPay through the method (sign, mint SPT, get card token)
  • VerifiesVerify binding, expiry and proof
  • OwnsSettle on the rail
  • OwnsHandle disputes and refunds

AP2

Relevance: None

Not one of the main personas on the AP2 page. The responsibility table gives this persona no step.

Mastercard Agent Pay

Relevance: None

Not one of the main personas on the Mastercard Agent Pay page. The responsibility table gives this persona no step.

Sources

  1. RFC: Agentic Commerce, Delegate Payment (external link)Agentic Commerce Protocol project. Specification, primary source. Accessed .
  2. ACP JSON Schema, Delegate Payment, 2026-04-17 (external link)Agentic Commerce Protocol project. Specification, primary source. Accessed .
  3. ACP OpenAPI, Delegate Payment, 2026-04-17 (external link)Agentic Commerce Protocol project. Specification, primary source. Accessed .
  4. Frequently Asked Questions, Google UCP Guide (external link)Google. Documentation, primary source. Accessed .
  5. Agentic Payments integration with UCP (external link)Adyen. Documentation, primary source. Published . Accessed .
  6. Universal Commerce Protocol (Stripe docs) (external link)Stripe. Documentation, primary source. Accessed .
  7. Payment Authentication extension (v2026-08-25) (external link)UCP Authors. Specification, primary source. Published . Accessed .
  8. order.json, fulfillment_event.json, adjustment.json schemas (v2026-08-25) (external link)UCP Authors. Specification, primary source. Published . Accessed .
  9. Card Network Charge Intent for HTTP Payment Authentication (draft-card-charge-00) (external link)Visa (J. Brans). Specification, primary source. Accessed .
  10. Stripe Charge Intent for HTTP Payment Authentication (draft-stripe-charge-00) (external link)Stripe and Tempo Labs. Specification, primary source. Accessed .
  11. GHSA-8mhj-rffc-rcvw / CVE-2026-34210: mppx Stripe charge credential replay (external link)GitHub Advisory Database. Other, primary source. Published . Accessed .
  12. Stripe docs: MPP (Machine Payments Protocol) (external link)Stripe. Documentation, primary source. Accessed .

Source details

    Loading the index.

    Enter open Esc close ? shortcuts