An AI agent finds a product, negotiates a condition, selects a merchant and initiates payment. The transaction is technically valid: the credential is active, the cryptogram verifies and the authorisation is approved.
But what, exactly, has been authenticated?
Conventional payment controls are designed primarily to establish that a recognised payer or credential initiated or approved a transaction. Agentic payments introduce an additional question: whether the autonomous action remained within the scope, context and limits of authority originally delegated by the customer.
That distinction is fundamental. Authenticating the customer does not, by itself, prove that:
the customer authorised this agent;
the agent was permitted to purchase this category of product;
the selected merchant was acceptable;
the final price remained within the authorised limit;
the mandate was still valid when payment occurred;
material transaction terms were not altered after approval; or
another agent, plugin or compromised tool did not manipulate the decision path.
Agentic payment authentication therefore requires more than a successful login, card-on-file token or Strong Customer Authentication (SCA) event. It requires an auditable chain of authority connecting human intent to agent identity, transaction context, payment credentials and execution.
The question is:
How can a payment provider prove that an autonomous transaction remained within the customer’s original mandate?
Agentic payments separate the payer from the transaction initiator
In a conventional e-commerce payment, the customer typically selects the item, reviews the amount, chooses a payment method and confirms the transaction within one session. Authentication, authorisation and checkout are closely linked.
In agentic commerce, those activities may be distributed across several actors and several sessions:
Customer or principal: the person or business that defines the objective and owns the funding source.
Consumer-facing agent: the system that interprets the customer’s intent and manages the purchasing task.
Specialist or sub-agent: another agent used for product search, negotiation, delivery, compliance or payment execution.
Agent provider: the organisation operating or supplying the agent.
Merchant agent or commerce platform: the system presenting products, prices and fulfilment terms.
Payment initiator: the component submitting the payment instruction.
Merchant PSP or acquirer: the party accepting and routing the payment.
Issuer or account-servicing PSP: the party controlling the payer’s credential or account.
These roles may be performed by different legal entities with different visibility into the transaction. The issuer may authenticate the customer but know little about the instruction given to the agent. The merchant may know which product was ordered but not whether the agent exceeded its authority. The agent provider may hold the intent history but not the final network authorisation record.
The architecture must therefore preserve evidence across organisational boundaries. A proprietary agent identifier or a merchant-side “AI transaction” flag is not enough.
The trust model requires four linked proofs
A defensible agentic transaction should produce four distinct but cryptographically related proofs.
1. Proof of principal identity
The system must establish who delegated authority. Depending on the use case, this may be a natural person, a corporate entity or a person acting under a business role.
The assurance level should match the risk. A low-value recurring grocery mandate may not require the same identity controls as an agent authorised to purchase travel, initiate treasury payments or acquire regulated goods.
2. Proof of agent identity
The relying parties must be able to distinguish a registered, authorised agent instance from an unverified bot, cloned agent or compromised execution environment.
Agent identity should be bound to:
the agent provider;
a unique agent or workload identifier;
the software or model version where relevant;
the credential used to sign requests;
its permitted capabilities;
its registration and assurance status; and
revocation and expiry information.
This does not mean exposing the model’s entire internal configuration. It means providing enough attestable identity and provenance for the parties taking payment risk.
3. Proof of delegated authority
The customer’s instruction must be translated into a machine-verifiable mandate. Natural-language intent alone is too ambiguous for enforcement.
“Book me a reasonable flight to Amsterdam” does not define whether the agent may select a non-refundable fare, add baggage, use a different airport, accept a long connection or spend above a particular amount.
The mandate must convert those preferences into structured constraints.
4. Proof of transaction conformance
At execution, the payment ecosystem must be able to verify that the actual transaction conformed to the mandate. The signed mandate and final payment instruction must be cryptographically bound to the same transaction context.
This final proof is the difference between showing that an agent had general authority and showing that it was authorised to make this particular purchase.
A mandate must be enforceable, not merely descriptive
Google’s Agent Payments Protocol illustrates the use of cryptographically signed mandates and verifiable credentials to preserve evidence of user instructions and transaction approval. The wider industry is moving toward comparable concepts, even where terminology and message structures differ.
A machine-readable mandate should contain, at minimum:
| Mandate element | Technical purpose |
|---|---|
Principal identifier | Identifies the party delegating authority |
| Authorised agent identifier | Restricts execution to a recognised agent or agent class |
Permitted action | Defines whether the agent may search, reserve, order or pay |
| Merchant constraints | Permits or excludes named merchants, countries or merchant categories |
| Product constraints | Defines acceptable products, quantities, attributes or regulated categories |
| Amount constraints | Sets per-transaction, cumulative and currency-specific limits |
| Time constraints | Defines validity, expiry and permitted execution windows |
| Frequency constraints | Limits transaction count or recurring activity |
| Funding-source constraints | Binds the mandate to an account, token or credential class |
| Approval conditions | Specifies when step-up or human confirmation is required |
| Sub-delegation policy | Determines whether the agent may appoint another agent or tool |
| Refund and substitution policy | Defines permitted post-purchase changes |
Nonce and mandate identifier | Prevents replay and supports traceability |
| Policy version | Records which rules were evaluated at execution |
| Signature and issuer data | Protects integrity and establishes provenance |
These constraints should be deterministic enough for a policy engine to evaluate. Where natural-language conditions remain necessary, the system should preserve both the original instruction and the structured interpretation, together with the model or ruleset used to perform the translation.
That translation is itself a risk boundary. If the customer says “up to €500 including all fees” but the structured mandate records a €500 base-price limit, the cryptographic signature only proves integrity of an incorrect interpretation.
Human-present and human-not-present flows require different evidence
Agentic purchases are not one authentication pattern.
Human-present execution
The agent assembles a final cart and asks the customer to approve it. The approval should bind the customer to the material transaction data:
merchant identity;
final amount and currency;
product or service;
delivery or performance terms;
recurring-payment conditions;
cancellation or refund restrictions; and
payment credential or account.
This resembles dynamic linking: the approval should be unusable if the payee or amount changes. The customer’s confirmation can generate a transaction-specific mandate whose hash is carried into the payment instruction.
Human-not-present execution
The customer creates a standing mandate and the agent acts later when defined conditions are satisfied, for example, “Buy this component when the delivered price falls below €300 before Friday.”
Here, the payment provider cannot rely on contemporaneous customer review. The system must evaluate the transaction against the standing mandate and retain evidence of:
the mandate’s validity at execution time;
the observed condition that triggered the purchase;
the product and merchant selected;
the policy decision permitting execution;
the agent and credential used; and
any risk-based step-up decision.
The absence of the customer at checkout makes mandate precision, replay protection and event integrity substantially more important.
Verifiable credentials can carry authority across trust domains
Verifiable credentials can allow an issuer, wallet, identity provider or agent registry to make signed claims that another party can validate without a bilateral integration for every relationship.
Relevant claims could include:
the principal has completed the required identity verification;
the agent is registered to a recognised provider;
the agent is authorised to perform a defined payment capability;
a payment credential is bound to that agent or mandate;
the mandate remains active; or
a transaction has received the required customer approval.
The verifier must still assess the credential issuer, status, scope and freshness. A technically valid signature is not proof that the issuer was authorised to make the claim or that the credential had not been revoked.
Europe’s developing EU Digital Identity Wallet payment-authentication model is relevant because it combines identity, payment authentication and cryptographically verifiable attestations. Agentic use cases will still require an additional delegation layer: proof that the identified person authorised a particular agent to act within a defined policy.
Payment tokens should be bound to authority, not only a device or merchant
Network tokenisation already reduces exposure of primary payment credentials. Agentic commerce requires more granular token controls.
An agentic token or token usage policy could be bound to:
the authorised agent identity;
the mandate identifier;
merchant or merchant-category restrictions;
product or service restrictions where payment messages support them;
maximum amount and cumulative spending;
currency and geography;
validity and execution window;
transaction frequency;
permitted rails or channels; and
step-up thresholds.
Tokenisation alone does not establish consent. A token proves that a substitute credential was used under token-domain controls. The surrounding mandate must prove why the agent was entitled to use it for the specific transaction.
The payment authorisation message should therefore carry, or resolve securely to:
an agent indicator and verifiable agent identifier;
a mandate reference or cryptographic digest;
the assurance level of customer authentication;
the execution mode human-present or delegated;
relevant policy results; and
a correlation identifier connecting commerce and payment records.
Sensitive mandate details need not be exposed to every intermediary. Selective disclosure, signed claims and reference tokens can provide the minimum information required by each participant while preserving an auditable source record.
SCA must be mapped to delegation, not assumed to solve it
Under PSD2 and Commission Delegated Regulation (EU) 2018/389, SCA is generally based on two or more independent elements from knowledge, possession and inherence, with dynamic linking for remote electronic payments.
Agentic payments raise a difficult sequencing question: when must the customer authenticate?
Possible models include:
SCA at mandate creation: the customer strongly authenticates when granting constrained authority to the agent.
SCA at transaction execution: the customer confirms each final purchase.
Risk-based hybrid: SCA establishes the mandate, but transactions outside defined parameters require step-up authentication.
PSP-controlled execution: the agent instructs a PSP-held mandate, while the PSP applies regulatory exemptions and transaction-risk analysis where legally available.
The correct treatment will depend on the payment rail, transaction characteristics, legal classification of the instruction and final regulatory interpretation. Firms should not assume that authenticating the customer once automatically satisfies SCA for every later autonomous payment.
The EU institutions reached a provisional political agreement on the revised payment-services framework in November 2025. The framework strengthens anti-fraud measures and consumer protection, but agentic-payment implementations still need precise legal analysis rather than treating “PSD3-ready” as a technical specification. The current legislative position can be followed through the Council of the EU payment-services timeline.
Dynamic limits should be evaluated as a policy graph
A single spending limit is too coarse for autonomous execution. Risk depends on the combination of customer, agent, merchant, product, time and behaviour.
A policy engine should evaluate:
per-transaction and cumulative amount;
velocity across merchants and agents;
deviation from the original product specification;
merchant trust and dispute history;
delivery-country and currency changes;
newly introduced sub-agents or tools;
unusual execution time;
price movement between selection and payment;
recurring or subscription terms;
product-risk category; and
changes to the funding source.
Policy outcomes should include more than approve or decline. A decision could:
permit autonomous execution;
request human confirmation;
require SCA step-up;
narrow the available payment instruments;
require merchant or product revalidation;
place the transaction on hold; or
revoke the agent’s authority.
The evaluated policy version and decisive inputs must be retained. Otherwise, the provider may know that the transaction was approved but be unable to reproduce why
Agent registration is a lifecycle, not a one-time check
Visa, Mastercard and other industry participants are developing mechanisms to distinguish legitimate agents from malicious automation. Visa’s Trusted Agent Protocol and Mastercard’s agentic-commerce work both reflect the need for recognisable agent identity and verifiable consumer intent.
A robust registry should support:
agent onboarding and provider verification;
cryptographic key registration and rotation;
capability declarations;
assurance level and certification status;
software or model-version attestations where required;
suspension and revocation;
compromise notification;
ownership or operator changes;
audit history; and
interoperable status checking.
Short-lived credentials reduce exposure but do not eliminate the need for revocation. An agent may be valid while a specific mandate has been withdrawn; equally, a mandate may remain valid while the agent credential is compromised. Agent, mandate, payment token and customer-session lifecycles must be managed independently but checked together.
Liability depends on where conformance failed
“The AI made a mistake” is not a useful liability category. Disputes should be analysed against specific control failures.
| Failure scenario | Primary evidence required | Potential control owner |
|---|---|---|
| Customer denies creating the mandate | Identity, authentication and signature evidence | Issuer, wallet or mandate provider |
| Agent exceeds amount or merchant limits | Mandate, policy evaluation and final transaction data | Agent provider and enforcing PSP |
Merchant changes price or product after approval | Signed cart, timestamps and merchant records | Merchant and acquirer |
| Compromised agent uses a valid token | Agent status, key history and token-domain controls | Agent provider, token service and issuer |
Sub-agent acts without permission | Delegation chain and capability records | Primary agent provider |
Duplicate or replayed instruction | Nonce, idempotency key and transaction history | Payment initiator and PSP |
Manipulated context changes agent decision | Provenance logs, signed inputs and policy trace | Agent and commerce platform providers |
PSP approves an out-of-policy payment | Authorisation data and mandate- conformance result | PSP or issuer |
Contractual allocation will vary, but technical evidence determines whether the allocation can be applied fairly. If no participant can reconstruct the chain of authority, liability will default to blunt scheme rules, consumer-protection requirements and bilateral disputes.
Chargebacks and refunds need agent-aware reason data
Existing dispute processes usually focus on whether the cardholder participated, received the goods or recognised the merchant. Agentic transactions introduce different questions:
Did the customer authorise the agent but not this product?
Did the agent select a non-refundable option outside the mandate?
Did the merchant fulfil the literal order while violating an approved attribute?
Was the payment authorised before a material substitution?
Did the agent accept a subscription or recurring obligation?
Was a refund routed to the original funding source or retained in an agent-controlled balance?
Networks and PSPs will need reason codes and evidence objects that distinguish identity failure, mandate failure, execution failure and fulfilment failure.
Merchants also need a way to prove what the agent saw and accepted. A conventional order confirmation may not be sufficient if the dispute concerns whether the agent was allowed to select that configuration.
Build an auditable transaction evidence envelope
Every agentic payment should produce a tamper-evident evidence envelope that can be reconstructed without relying on one provider’s application logs.
The envelope should include:
principal and authentication assurance;
agent identity and registry status;
original human instruction;
structured mandate and policy version;
delegation and sub-delegation chain;
signed cart or transaction terms;
final payment instruction and credential reference;
mandate conformance result;
risk and step-up decisions;
network authorisation identifiers;
timestamps, nonces and correlation identifiers;
merchant fulfilment evidence; and
revocation and credential status data relevant at execution time.
These records should be integrity protected, access controlled and retained according to legal, scheme and privacy requirements. Data minimisation remains essential: auditability does not justify distributing the customer’s full conversational history across the payment chain.
An implementation test for banks, PSPs and merchants
Before enabling autonomous execution, each participant should be able to answer:
Can we identify the agent independently of its user agent string or API client name?
Can we verify who granted authority and at what assurance level?
Can we evaluate the mandate without interpreting free text at authorisation time?
Can we bind the final merchant, amount and material terms to the mandate?
Can we detect unauthorised sub-delegation?
Can we revoke the agent, mandate and payment credential independently?
Can we trigger human confirmation when risk or transaction context changes?
Can we reproduce the exact policy decision months later?
Can we provide intelligible evidence to a customer, regulator or dispute handler?
Can we determine which party failed if the transaction departs from intent?
If the answer to any of these questions is no, the organisation may be able to process an AI-initiated payment, but it cannot yet demonstrate trustworthy delegated execution.
The next payment credential is authority itself
Agentic commerce will not scale on bot detection and tokenisation alone. The payment ecosystem must make authority portable, constrained, revocable and provable.
The most important control is not whether an AI agent can present a valid payment credential. It is whether the bank, PSP and merchant can independently verify that:
the right customer authorised the right agent;
the authority covered the specific transaction;
material terms remained unchanged;
execution stayed within policy; and
the complete evidence chain survives a dispute.
The organisations that solve this will move payment authentication beyond proving possession of a credential. They will authenticate delegated intent itself.
Continue the Conversation in Amsterdam
The Next-Gen Payments Blueprint Summit 2027 will bring together senior leaders from banks, payment service providers, FinTechs, merchants, infrastructure providers and regulators to examine the systems shaping the next generation of European and global payments.
17–18 March 2027
Amsterdam, the Netherlands
Click here to request the Agenda for : The Next-Gen Payments Blueprint Summit
Interested in attending as Delegate or Product Launch, Workshop, Masterclass, Webinar, Speaking, Exhibiting, Panelist,Round Table Discussion lead? Click here to request the agenda and discover how your organization can be part of Europe’s next-generation payments conversation.