Agentic Rails Atlasby merces.ai

Persona

AI surface product lead

Runs a chat or search surface (ChatGPT, Gemini, Copilot); wants conversion, trust and clear liability.

Verified (verified under 30 days ago)

Role

Goals

  • Let users complete a purchase inside the conversation with a checkout that finishes in one or two turns.
  • Onboard many merchants through one protocol (ACP or UCP) instead of bespoke integrations.
  • Stay out of the merchant-of-record role: the merchant keeps orders, taxes, returns and compliance.
  • Prove to users and regulators that the agent bought what the user asked for and nothing else.
  • Carry a payment credential through checkout without ever holding raw card data.
  • Measure attribution: which recommendations led to orders, and what the platform earns from them.

Pains

  • Instant Checkout in its 2025 form was scaled back because merchants wanted their own checkout, so the surface now sends traffic out and loses control of the final step.
  • Liability for a wrong or disputed agent purchase is not settled by Visa or Mastercard rules, and the platform is the most visible party to blame.
  • Each merchant supports a different subset of capabilities and payment handlers, so the checkout experience varies and negotiation adds latency.
  • Prompt injection on merchant pages and in product feeds can bias the agent, and users will hold the platform responsible.
  • Merchants object that platform checkout bypasses their pixels and customer data, and some have gone to court over scraping (Amazon v. Perplexity).
  • Governance of ACP and UCP sits with a few firms, one of which may be a direct competitor.

Decisions they own

  • Which commerce protocol to adopt as primary, and whether to support both ACP and UCP.
  • Whether to host checkout inside the surface or hand off to the merchant with a continue_url.
  • Which credential providers and PSPs can supply payment tokens to the surface.
  • What user-intent proof (an AP2 mandate, Verifiable Intent, or nothing beyond a scoped token) to require before a payment.
  • How to rank and disclose sponsored or affiliate results inside agent recommendations.

Vocabulary

  • checkout session
  • merchant of record
  • product feed
  • payment handler
  • Shared Payment Token
  • delegate payment
  • UCP-Agent profile
  • capability negotiation
  • continue_url
  • conversion
  • attribution
  • escalation
  • API-Version

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: High

Operates the AI agent as an Agent Provider onboarded to Visa Intelligent Commerce and signs every merchant request with its registered key. Source [1, 2, 3, 4]

Goals

  • Get past merchant bot defenses
  • Complete purchases with VIC credentials
  • Keep one signing setup across Visa and Mastercard

Pains

  • The client implementation guide is only for onboarded agents
  • Body object signing has no canonical form or test vector
  • Two networks with different tags and directories

Implements

  • RFC 9421 signing with the TAP tags and an 8-minute window
  • Signed agenticConsumer and agenticPaymentContainer objects
  • VIC calls for card enrollment, instructions, credentials and confirmations

Must trust

  • Visa to keep its key in the key store
  • Checkout Enablers and CDNs to pass headers intact
  • Merchants to treat the consumer data with care

Questions they ask

  • Which merchants verify TAP today?
  • How should I serialize the body object signature base?
  • Must I send both a TAP and a Web Bot Auth signature?

First three steps

  1. Apply for VIC onboarding and obtain the client guide
  2. Sign browsing requests with agent-browser-auth against a test merchant
  3. Add the payment container at checkout with the same key and nonce

Metrics they care about

  • Agent checkouts blocked by bot defenses
  • Checkout success rate per merchant
  • Signature verification failures reported by merchants

A day in the life. Priya builds the shopping agent for an AI assistant. After VIC onboarding, her agent signs each product page request with agent-browser-auth and each checkout with agent-payer-auth, inside an 8-minute window. Checkout also needs the two signed objects, and her first build fails at a merchant because the merchant joined the fields in a different order. With no test vector in the specification, she agrees a byte format with that merchant and files the question with Visa. The user's passkey approval sits in VIC, so her agent never asks for a card number.

Steps in the responsibility table

  • ImplementsOnboard the agent and register its key
  • OwnsSign each request with a TAP tag
  • Relies onVerify header signature, window and nonce
  • OwnsSign the consumer and payment objects
  • ImplementsApprove the purchase instruction with a passkey (VIC)

Agentic Commerce Protocol (ACP)

Relevance: High

Runs the agent surface: calls merchants' checkout APIs, obtains delegated tokens, hosts the order webhook receiver and, since 2026-04-17, the Feed API. Source [5, 6, 7, 8]

Goals

  • Let buyers complete purchases without leaving the conversation
  • Onboard many merchants on one contract
  • Keep card data out of the model and the merchant API

Pains

  • Each merchant needs its own bearer key and onboarding
  • Merchants implement different versions and drift from the examples
  • Six checkout statuses have no RFC definition

Implements

  • Checkout client for create, update, complete and cancel
  • Delegate Payment call with an allowance per purchase
  • Merchant-Signature verification on /agentic_checkout/webhooks/order_events
  • Feed API endpoints for pushed products

Must trust

  • The merchant to return authoritative totals and honor its own messages
  • The PSP to enforce the allowance
  • The merchant's webhook secret handling

Questions they ask

  • Which API-Version does this merchant support?
  • Should we accept both order_create and order_created?
  • How do we show a requires_escalation session?

First three steps

  1. Read the 2026-04-17 JSON Schema and OpenAPI files
  2. Run the repository validation script against your own payloads
  3. Integrate one merchant end to end with Idempotency-Key on every POST

Metrics they care about

  • Checkout completion rate
  • Share of sessions ending in messages with resolution requires_buyer_input
  • Webhook signature failures
  • Time from create to completed

A day in the life. Priya leads checkout on an assistant app. A buyer asks for a lamp, and her client creates a session at the merchant with a fresh idempotency key. The merchant returns not_ready_for_payment and a message that the address is missing. The assistant asks, sends an update, and the session turns ready_for_payment. After the buyer confirms 84 dollars, Priya's service asks the PSP for a token capped at exactly that amount, bound to this merchant and session, valid for fifteen minutes. Completion returns an order link. Two days later a signed order_update says shipped, and her receiver rejects a replayed copy that arrives outside the 300-second window.

Steps in the responsibility table

  • Relies onPublish /.well-known/acp.json
  • OwnsCreate and update the checkout session
  • Relies onReturn authoritative totals and messages
  • ImplementsConfirm the purchase
  • OwnsSet the allowance (max_amount, merchant, session, expiry)
  • Relies onIssue and vault the token
  • VerifiesSign and verify order webhooks
  • ObservesHandle refunds and chargebacks

UCP

Relevance: High

The platform: an agent surface that discovers businesses, negotiates capabilities, fills checkouts and hands the buyer a trusted review screen. Source [9, 10, 11, 12]

Goals

  • Buy from many stores with one protocol
  • Keep the buyer in control of the final purchase
  • Pass payment without touching raw card data

Pains

  • Every business can advertise a different capability set and version
  • Permissionless onboarding means businesses may still block unknown platforms
  • Documentation drift between ucp.dev pages and the schemas

Implements

  • A platform profile with keys and an order webhook_url
  • Namespace authority checks and schema resolution
  • Payment handler execution and the trusted checkout UI

Must trust

  • The business profile and its schema URLs
  • Credential providers to issue valid tokens
  • Businesses to honor idempotency keys

Questions they ask

  • What happens if the complete response is lost?
  • Which handlers can we execute on our surface?
  • Do we need the AP2 extension to place orders without a human click?

First three steps

  1. Publish a platform profile with an ES256 key
  2. Implement the intersection and pruning rules against two test profiles
  3. Wire the trusted review screen and the continue_url handoff

Metrics they care about

  • Share of businesses with a compatible intersection
  • Time from create to completed
  • Escalations per 100 checkouts

A day in the life. Ravi runs the shopping agent of a large assistant app. Each store his agent visits has a slightly different profile: one offers cart and loyalty, another only checkout. His code picks the highest common version, prunes the loyalty extension when checkout is missing, and sends the platform profile in UCP-Agent on every call. One night a store times out on complete. The agent polls Get Checkout, sees complete_in_progress, and waits instead of resending. The order shows up as completed an hour later, with one charge. Ravi adds the case to his test suite and moves on to identity linking.

Steps in the responsibility table

  • Relies onPublish /.well-known/ucp with keys
  • OwnsAdvertise UCP-Agent and verify the platform profile
  • Relies onCompute the capability intersection
  • OwnsFill the checkout (full-replacement updates)
  • ImplementsReview and place the order in a trusted UI
  • ImplementsEscalate with continue_url
  • Relies onWrite the payment handler spec
  • ImplementsIssue the opaque token
  • VerifiesSign the checkout and verify the AP2 mandate
  • VerifiesSend signed order webhooks
  • ObservesHandle refunds and disputes

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: High

Builds the agent: registers it with Mastercard, captures consent, requests tokens and signs every merchant request. Source [13, 14, 15, 16, 17, 18]

Goals

  • Let users buy through the agent at any Mastercard merchant
  • Pass certification once and reuse it
  • Hold tokens, never card numbers

Pains

  • No public SDK, API reference or sandbox for Agent Pay
  • Two spellings of the tag and an example directory host that does not resolve
  • Form filling on pages built for people

Implements

  • Agent key pair and registration
  • Consumer authentication and limit capture
  • RFC 9421 request signing with the Agent Pay tag

Must trust

  • Mastercard to keep the agent listed
  • Merchants and CDNs to verify signatures
  • The consumer passkey flow

Questions they ask

  • Which tag spelling do verifiers accept?
  • How do I get a token through Stripe instead of directly?
  • When will Verifiable Intent be required?

First three steps

  1. Read the Rails for Agentic Commerce and Level 1 guides
  2. Prototype signing with RFC 9421 and test against a CDN
  3. Run the Verifiable Intent Python examples locally

Metrics they care about

  • Checkout completion rate
  • Signature verification failures
  • Time from consent to token

A day in the life. Sam leads payments at a startup building a shopping agent. He wants users to say "book two tickets for Friday" and have the agent finish the purchase at any merchant. Agent Pay requires a registered key, a security review and tokens instead of card numbers, which suits him, but there is no public SDK or sandbox. He signs requests with RFC 9421 and tests both spellings of the tag. For merchants on Stripe he considers Shared Payment Tokens, which carry Mastercard agentic tokens. He also runs the Verifiable Intent examples, expecting signed intent to become part of certification.

Steps in the responsibility table

  • ImplementsRegister agent key and pass certification
  • ImplementsAuthenticate consumer and set limits
  • ImplementsProvision agentic token
  • OwnsSign request with Agent-pay-auth tag
  • Relies onVerify signature at edge or backend
  • ImplementsVerify Verifiable Intent chain

Sources

  1. Trusted Agent Protocol merchant specifications (external link)Visa. Specification, primary source. Accessed .
  2. Trusted Agent Protocol overview (Visa Developer Center) (external link)Visa. Documentation, primary source. Accessed .
  3. Visa Intelligent Commerce overview (Visa Developer Center) (external link)Visa. Documentation, primary source. Accessed .
  4. visa/trusted-agent-protocol repository metadata, commits, pull requests and issues (GitHub API) (external link)GitHub. Repository, primary source. Accessed .
  5. RFC: Agentic Checkout, Merchant REST API (external link)Agentic Commerce Protocol project. Specification, primary source. Accessed .
  6. ACP JSON Schema, Delegate Payment, 2026-04-17 (external link)Agentic Commerce Protocol project. Specification, primary source. Accessed .
  7. ACP OpenAPI, Agentic Checkout Webhooks, 2026-04-17 (external link)Agentic Commerce Protocol project. Specification, primary source. Accessed .
  8. ACP JSON Schema, Agentic Checkout, 2026-04-17 (external link)Agentic Commerce Protocol project. Specification, primary source. Accessed .
  9. UCP Official Specification overview (v2026-08-25) (external link)UCP Authors. Specification, primary source. Published . Accessed .
  10. Checkout Capability (v2026-08-25) (external link)UCP Authors. Specification, primary source. Published . Accessed .
  11. UCP Message Signatures (v2026-08-25) (external link)UCP Authors. Specification, primary source. Published . Accessed .
  12. Identity Linking Capability (v2026-08-25) (external link)UCP Authors. Specification, primary source. Published . Accessed .
  13. The Rails for Agentic Commerce (external link)Mastercard Developers (Merchant Cloud tutorials). Documentation, primary source. Accessed .
  14. Level 1 Agentic Commerce: Enable Agent Support with Minimal Changes (external link)Mastercard Developers (Merchant Cloud tutorials). Documentation, primary source. Accessed .
  15. Preparing for Agentic Commerce: Testing, Validation, and Reference Guide (external link)Mastercard Developers (Merchant Cloud tutorials). Documentation, primary source. Accessed .
  16. Supporting additional payment methods for agentic commerce (external link)Stripe Blog. Announcement, primary source. Published . Accessed .
  17. Verifiable Intent README (external link)agent-intent (maintained by Mastercard). Repository, primary source. Published . Accessed .
  18. Mastercard Developers llms.txt service index (external link)Mastercard Developers. Dataset, primary source. Accessed .

Source details

    Loading the index.

    Enter open Esc close ? shortcuts