agentwallets.si
← Back to Blog

EDITORIAL ARTICLE

Mastercard Agent Pay: Bringing Cardholder Intent Into Agent Transactions

Article concepts · illustration
01Cardholder intent02Agent credential03Merchant transaction

Payment network, authorization trust and machine payments · Sources checked October 28, 2026. For banks, merchants, agent platforms and infrastructure providers; not tested.

You ask an agent to buy shoes costing no more than $100. When a merchant receives a payment request, how can it tell the transaction is within your authorization? Mastercard’s approach includes Agent Pay, agent-specific credentials and Verifiable Intent for expressing user authorization. It is also exploring agents purchasing APIs, data and compute at high frequency.

Background and position

Mastercard operates a global payment network and offers related technology and services. Agent Pay is a set of capabilities connecting to that network and trust system, not a standalone agent wallet automatically containing funds. Issuers, merchants and integration partners provide user funds, cards, acceptance and permission implementation. Agent Pay for Machines (AP4M) addresses programmatic, small-value or high-frequency machine transactions. See Agent Pay and the AP4M announcement.

A conceptual constrained purchase

flowchart LR U[User states purchase conditions] --> A[Agent selects product] A --> I[Record and verify authorized intent] I --> T[Restricted payment credential] T --> M[Merchant and payment participants process] M --> R[Return order and transaction result]

In March 2026, Mastercard and Google described Verifiable Intent: tamper-resistant records and cryptographic proofs expressing user authorization, intended to help merchants and issuers check agent behavior. Mastercard said it aligned with AP2 and UCP and was designed for cross-protocol use; it described connecting the Agent Pay intent API as future work at that time. A public specification does not mean every merchant has deployed it or that all preferences can be fully expressed by machines. See Verifiable Intent.

Capability Intended problem What needs confirmation
Registered agents and network credentials Distinguish participants and reduce exposure of raw card details Registration and participating platforms and issuers
Verifiable Intent Record and verify what a user permits How consumers confirm, change and revoke; dispute responsibility
Agent Pay Coordinate supported agent-initiated transactions Regions, merchants, cardholder verification and after-sales service
AP4M Small, high-frequency machine transactions Actual availability, latency, prices and contractual settlement assurances

As of October 29, 2026, Mastercard’s Cloudflare Connect early-access page labeled AP4M a pilot and said it was not commercially available. This should not be confused with broad commercial deployment.

Announced in June 2026, AP4M is described as designed for multiple payment methods from cards to stablecoins, with a list of supporters. A partnership announcement establishes direction and named partners, not that every partner has launched every feature. Whether a half-cent transaction is economic depends on real fees, aggregation and settlement arrangements. See AP4M.

Business model and competition

Mastercard’s established income includes network and related services. The sources above do not disclose Agent Pay-specific rates, revenue sharing or charges for each machine transaction. The company may seek to preserve network value in new channels through verifiable intent, credentials and settlement; that is analysis, not a revenue finding.

Like Visa TAP, Mastercard is building identity and control layers for trusted agent payments. Verifiable Intent emphasizes verifiable user intent; actual security and openness require implementation-level comparison. Nevermined centers on AI-service metering, plans and authorization, while Mastercard centers on its network and partners; their layers may cooperate.

Ask whether users approve each transaction, who issues and retains intent evidence, who handles refunds and disputes, whether authorization survives a substituted product or merchant, and which AP4M settlement paths are actually available in the target region.

Three questions behind one card

The shoe request involves at least three layers: whom the agent represents and what the user authorized; the scope of the payment token; and whether the issuer and network approve the card transaction. Verifiable Intent focuses on a verifiable record of the first; an agentic token supplies a restricted payment credential; payment approval and fulfillment remain responsibilities of the relevant participants. Even a valid purchase request can fail because of stock, authentication or a declined payment. See Verifiable Intent and Agent Pay.

If tax takes the total above $100, does the limit apply to the listed price or final total? This is necessary authorization detail, but public information does not establish a uniform rule for every integration. Users need ways to review and change permissions; issuers and merchants need procedures for mismatched authorization, missing records and disputes.

Why machine payments are a separate business problem

Mastercard describes AP4M as intended for many low-latency, low-value machine transactions, including data, compute and logistics. For a $0.001 API request, economic viability depends on whether platform and network fees consume the transaction’s value, whether settlement requires aggregation and how the seller confirms payment. Public launch material describes multiple payment and settlement methods but does not provide a uniform fee or latency guarantee from which to calculate this example. It cannot prove micropayments will always be cheaper. See the AP4M announcement.

Question Consumer shopping Machine API purchase
Authorization Product, amount, merchant and delivery terms Service, budget, frequency and duration
Pace Usually centered on an order Potentially continuous or high-frequency
Result Order, shipping and return API result, allowance and failure retries
Pricing Merchant/cardholder charges and return cost Per-request and aggregated-settlement costs

This is scenario analysis, not a deployment guarantee. A partner list demonstrates public support for a direction, not that each partner supports every asset or service.

Verification and after-sales support

Before integration, request evidence for a test order linking user authorization, agent identity, credential restrictions, merchant order, network response and visible status. Ask about revocation, card updates, refunds and disputes, especially who decides when user authorization differs from the actual order. Partners and contracts must answer these questions; a cryptographic record is not an automatic refund promise.

Sources