Agentic Rails Atlasby merces.ai

Persona

Wallet or credential provider

Holds credentials, captures consent, issues tokens (Google Pay, PayPal, Coinbase).

Verified (verified under 30 days ago)

Role

Goals

  • Be the place where the user grants, sees and revokes agent spending permissions.
  • Capture consent on a trusted, non-agentic surface and bind it to a mandate the agent cannot alter.
  • Issue a payment credential (a token, an SPT, an agentic token) that is scoped to the mandate and verifiable downstream.
  • Author a payment handler spec that merchants and platforms adopt (com.google.pay, dev.shopify.shop_pay).
  • Hold a key the agent cannot reach, so the provider signs on the user's behalf for autonomous flows.
  • Support both card and stablecoin credentials for the same user and agent.

Pains

  • AP2 defines no mandate revocation, so a user who changes their mind has no protocol-level path.
  • Delegation models differ: a user credential with OpenID4VP transaction_data, or a provider key. The Digital Credentials API is not available everywhere.
  • Credential data flows one way in UCP, so the provider learns little about what happened after issuance.
  • Every surface and merchant wants a different credential type (token, PAN, network token), and some still want raw PAN.
  • Verifiable Intent, AP2 and SPT allowances overlap, and the provider must map one consent to several formats.
  • If the agent and the wallet belong to the same company, regulators ask whether the consent surface is truly independent.

Decisions they own

  • Which mandate format to issue and verify (AP2 v0.2, Verifiable Intent, proprietary).
  • Default limits for autonomous permissions: lifetime, budget, allowed payees.
  • Whether to present the user's own credential or sign with a provider key.
  • Which networks' agentic tokens to support and how to display them to the user.

Vocabulary

  • mandate
  • SD-JWT
  • key binding
  • cnf
  • Trusted Surface
  • credential provider
  • payment handler
  • passkey
  • OpenID4VP
  • Digital Credentials API
  • allowance
  • revoke
  • consent
  • network token

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

Not one of the main personas on the Agentic Commerce Protocol (ACP) page. The responsibility table gives this persona no step.

UCP

Relevance: High

The credential provider: writes a payment handler specification and issues opaque tokens to platforms. Source [1, 2, 3, 4, 5]

Goals

  • Make its wallet a payment option in every agent checkout
  • Keep raw credentials inside its own systems
  • Bind tokens to a merchant and a session

Pains

  • UCP defines the handler format but no concrete handler, so each provider documents its own
  • Platforms must execute the handler correctly on many surfaces
  • Google surfaces use Google Pay with PAN_ONLY, which limits token types there

Implements

  • A handler spec under its own reverse domain, for example com.google.pay
  • Token issuance to platforms
  • Optional AP2 support for user-signed mandates

Must trust

  • Platforms to run the handler as written
  • Businesses to configure merchant settings correctly
  • PSPs to accept its tokens

Questions they ask

  • Which credential type do we return: token, PAN or network token?
  • How do businesses publish our config?
  • Do we support the digital payment credential model of the AP2 extension?

First three steps

  1. Read the payment architecture section of the overview
  2. Publish a handler spec and schema under your own domain
  3. Test with the samples and one PSP

Metrics they care about

  • Handler adoption by businesses
  • Token approval rate at PSPs
  • Share of checkouts using the handler

A day in the life. Ana works on a wallet team that wants its button in agent checkouts. She writes a handler spec under the wallet's own domain, because dev.ucp is reserved, and a schema for the business config. Businesses add the handler to their profile with their merchant id. Platforms run the handler, get a token bound to the merchant and session, and pass it in payment.instruments. Ana never sees the checkout itself, and the business never sees the card number. Her open question is AP2: the extension lets a wallet sign mandates with a key bound to a payment credential, but she has not found a deployment that does it yet.

Steps in the responsibility table

  • OwnsWrite the payment handler spec
  • OwnsIssue the opaque token
  • Relies onAuthorize and settle the token
  • ImplementsSign the checkout and verify the AP2 mandate

AP2

Relevance: High

Credential Provider: verifies Payment Mandates and issues a token scoped to the purchase; often also hosts the Trusted Surface. Source [6, 7, 8, 9]

Goals

  • Release credentials only for approved purchases
  • Offer agent payments without new fraud exposure
  • Reuse existing tokenization

Pains

  • Stateful constraints (budget, recurrence) need presentation history
  • No revocation primitive for open mandates
  • Specification moved to FIDO with no public draft

Implements

  • Delegate SD-JWT chain verification
  • Constraint evaluation for payment.* types
  • Payment Receipt handling and error codes
  • OpenID4VP delegation with type delegate when acting as wallet

Must trust

  • The user credential issuer or the trusted agent provider list
  • The network to honor scoped credentials
  • Its own deterministic code, never an LLM

Questions they ask

  • How do I track payment.budget across presentations?
  • Which delegation model do my verifiers accept?
  • How do I invalidate tokens from overlapping mandates?

First three steps

  1. Read agent_authorization.md and payment_mandate.md at v0.2.0
  2. Run the Python SDK chain verification against the schema examples
  3. Map each failure to invalid_credential, invalid_mandate or unresolved_constraint

Metrics they care about

  • Share of presentations rejected by error code
  • Token issuance latency after mandate verification
  • Fraud rate on mandate-backed tokens

A day in the life. Marco runs the agent payments team at a digital wallet. Each morning he reviews rejected presentations by error code. Most invalid_credential cases come from one agent provider whose closed mandates are signed with a rotated key that no longer matches cnf. The unresolved_constraint cases are mostly budget checks: his service is the one that has to remember earlier presentations, and the specification never said whose job that was. He files a note for the FIDO payments group about revocation, then adds a rule that invalidates outstanding tokens when the agent presents an overlapping mandate. The release goes out with ES256 keys only.

Steps in the responsibility table

  • ImplementsApprove Mandate Content on the Trusted Surface
  • OwnsVerify the Payment Mandate and issue a token
  • OwnsTrack budget and recurrence state
  • ImplementsReturn signed receipts
  • VerifiesVerify mandates and receipts in a dispute
  • ImplementsSet retention and consent policy

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. UCP Official Specification overview (v2026-08-25) (external link)UCP Authors. Specification, primary source. Published . Accessed .
  2. Payment type schemas (v2026-08-25) (external link)UCP Authors. Specification, primary source. Published . Accessed .
  3. AP2 Mandates Extension (v2026-08-25) (external link)UCP Authors. Specification, primary source. Published . Accessed .
  4. Agentic Payments integration with UCP (external link)Adyen. Documentation, primary source. Published . Accessed .
  5. Frequently Asked Questions, Google UCP Guide (external link)Google. Documentation, primary source. Accessed .
  6. AP2 Agent Authorization (external link)Google (google-agentic-commerce). Specification, primary source. Published . Accessed .
  7. AP2 Payment Mandate (external link)Google (google-agentic-commerce). Specification, primary source. Published . Accessed .
  8. AP2 Security and Privacy Considerations (external link)Google (google-agentic-commerce). Specification, primary source. Published . Accessed .
  9. Agentic Payment Protocol (v0.2) specification (external link)Google (google-agentic-commerce). Specification, primary source. Published . Accessed .

Source details

    Loading the index.

    Enter open Esc close ? shortcuts