Designing for Agent Payment Standards You Cannot Yet Choose Between: A Protocol-Agnostic Architecture for Agentic Checkout
If you are an engineering leader at a UK retailer or payment service provider, you are being asked to support agent-initiated checkout without knowing which standard will matter in two years. The October reporting makes the problem sharper rather than smaller. Mastercard, American Express and Google each announced something agent-related within a few weeks of one another, and none of them points at the same technical design. The usual advice is to pick the likely winner and move quickly. We think that is the wrong shape of decision. The better question is how to build so that picking wrong is cheap.
What the October launches tell you, and what they do not
Here is what was reported, in the order it matters for architecture.
Mastercard opened early access to Agent Pay for Machines, with buyer-side and seller-side APIs and a sandbox. It is explicitly machine-to-machine, meaning agents paying for services, rather than only consumer shopping. American Express published an "Intent Intelligence" framework that links authenticated purchase intent to agent transactions. Google launched Universal Cart in the United States, with checkout through its Universal Commerce Protocol and Google Pay. Alongside the networks, an identity layer is forming: reports that week covered Sumsub's agent-authorisation module, Proof's x401, World ID, Evervault and a Skyfire and Forter partnership. Machine-to-machine payments are also developing on stablecoin and onchain rails, with Circle's managed payments product, a Tether and AIsa arrangement and x402 all reported.
Our synthesis, and it is a synthesis rather than a reported fact, is that these are separate bets. Each network or platform is sponsoring its own approach, none is displacing the others, and fragmentation is widening rather than narrowing. That reading carries medium confidence. It rests on a handful of launches, several of which are early access or US-only, and standards landscapes can consolidate faster than anyone expects. The names on most lists, such as AP2, ACP, x402 and UCP, will not all matter equally, and we are not going to predict which will.
What the launches do not tell you is which of these your customers' agents will present at your checkout. A UK retailer and a London PSP may meet different agents carrying different credentials, and neither controls which. That uncertainty is the design constraint.
Why picking a protocol is the wrong first decision
Teams that commit early to one scheme risk rework. The cost is rarely the protocol integration itself, which is a bounded piece of work. It is the way the integration leaks into everything around it. If your order service speaks one protocol's vocabulary, your risk rules reference one scheme's fields and your reconciliation job expects one scheme's settlement format, then adding a second scheme means touching all three. The protocol was supposed to be an edge concern. It has become a core one.
This article is deliberately not a protocol comparison. A feature-by-feature comparison ages within weeks, and it answers the wrong question for an architect: knowing how two standards differ does not tell you where in your system the difference should be absorbed.
The principle we would apply is simple: translate at the edge, and think in your own language at the core. Every external standard is an adapter at the boundary. Inside the boundary, your system uses a small set of concepts that you own and that outlive any one standard. That is the core of building for agentic commerce and payments in a market that has not settled.
A four-layer architecture for agentic checkout
The four layers below are our own framework, built from the recurring concerns that the different approaches all have to address. They are not a standard, and they are not taken from any network's documentation. What they share is that each answers a question that every agent payment has to answer, whichever protocol carries it.
Layer one: agent identity and authority
The question: who is acting, and on whose behalf?
This layer represents the agent, the principal it represents and the relationship between them. It should record how the agent was identified (which identity scheme, with what level of assurance) and what the principal delegated. The reports of agent identity tooling multiplying in a single week, with no single standard emerging and several approaches coexisting, are the best argument for keeping this layer abstract. An internal "agent identity" object with a pluggable verification method is far cheaper to change than identity assumptions scattered through your checkout code.
Do not model identity as a boolean. Store who vouched for the agent, how recently and for what scope, not just the verdict.
Layer two: the mandate
The question: what exactly has the agent been authorised to do?
The mandate is the heart of the architecture, and it is the object we would most urgently own. It expresses scope in your terms: the merchant or category, the ceiling in pounds, the validity window, the conditions such as price limits or required substitutions, and whether a human must confirm. Different schemes will represent authority differently, whether as signed intent, network-issued tokens bound to constraints or something else. Your mandate object is the canonical form that all of them are translated into and out of.
The strongest reason to centralise it is liability. The most prominent agentic-commerce theme in recent reporting is who authorises an agent's transaction and who bears the loss when it goes wrong. If you hold the mandate in a single, versioned, auditable form, you can answer that question regardless of which scheme carried the instruction. If it lives in five adapters, you cannot.
Layer three: the tokenised payment instrument
The question: what credential actually moves the money, and who holds it?
An agent should rarely, if ever, hold a raw card number or a customer's banking credentials. This layer wraps the instrument in a token or equivalent handle and records its type, its binding to a mandate, its expiry and its revocation status. Instruments will differ: a network token, a wallet-held credential, an account-to-account mandate or a stablecoin transfer. Your core treats them as variations of one thing, an authorised, constrained, revocable way to pay.
The practical advice here is to resist the temptation to flatten everything to a lowest common denominator. Some instruments carry properties others do not, such as a network's built-in intent data. Model a small common core, and let each instrument type carry typed extensions. The adapter then decides what to pass through, and your risk engine can use the extras when they exist without requiring them.
Layer four: settlement and events
The question: what happened, and can we prove it?
The final layer is a canonical event stream for the life of an agent transaction: mandate created, mandate used, payment authorised, captured, settled, refunded, disputed, revoked. Each scheme has its own lifecycle and its own settlement timing, and these will not line up neatly. Your finance, fraud and customer-service teams should not need to learn each scheme's vocabulary. They should read one event model, and each adapter should translate into it.
This is also where your audit trail lives. For regulated businesses, the ability to show who authorised what, under which scope, and what followed is not a nice-to-have. We return to that point in the UK section below.
The adapter edge: where each standard belongs
With the four layers in place, a protocol becomes an adapter with a narrow job: receive the scheme's messages, verify what the scheme says can be verified, and translate into the canonical identity, mandate, instrument and event objects. On the way out, it translates your decisions back into the scheme's language.
A few rules keep the edge healthy.
- One adapter per scheme, no cross-talk. An adapter should not call another adapter or branch on which other schemes are live. Cross-talk is how the edge becomes the core.
- Capabilities, not names. Let each adapter declare what it can do, such as supporting a ceiling, a revocation or a refund, and let the core route on capabilities. Branching on a protocol name in business logic is the clearest symptom of leakage.
- Contract tests at the boundary. Because several schemes are in early access or sandbox stages, their behaviour will change. A suite that replays recorded scheme messages against your canonical model tells you what broke the day a scheme updates, rather than the day a customer complains.
- Feature flags for each scheme. Switch a scheme on for a small share of traffic, or off, without a deployment.
Mastercard's sandbox for Agent Pay for Machines is a useful illustration: a sandbox is where you find out whether your mandate model can express what a scheme sends, long before production traffic arrives.
What not to abstract
Protocol-agnostic does not mean abstract everything. Three traps are worth naming.
Do not invent a universal protocol. The aim is not to build your own standard and ask the market to adopt it. It is an internal model small enough to map onto the standards that matter to you.
Do not abstract before you have two cases. One adapter tells you little about the right shape of the core. Start with the model implied by the first scheme you support, and expect to revise it when the second arrives. The architecture is the discipline of keeping the revision local, not a claim that you got the model right first time.
Do not hide differences that matter commercially. If one scheme gives you better fraud signals or lower dispute rates, your routing logic should know. Abstraction should remove accidental differences, not conceal real ones.
The UK dimension: accountability does not wait for standards
For UK firms, the architecture is also a compliance asset. On 19 October the FCA published what it described as good and poor practice in AI, and it said that AI providers should add disclaimers to AI financial advice. As reported, it is applying existing frameworks, including Consumer Duty and senior-manager accountability, to AI rather than creating new agent-specific rules. That is general context, not legal advice, and firms should take their own advice on how it applies to them.
The implication for architecture is practical. When accountability attaches to outcomes rather than to a particular technology, you need to be able to show outcomes whichever protocol delivered the instruction. A canonical mandate and event stream give you that. A set of scheme-specific logs does not.
Consumer behaviour points the same way. Surveys reported in October found that willingness to use AI to research outpaces willingness to let it complete a purchase. Delegated checkout is therefore likely to arrive unevenly: first in contexts with existing approvals and audit trails, such as business-to-business invoice payments, where Visa, BILL and Billtrust are running a live pilot through Visa Intelligent Commerce, and later in open consumer shopping. Visa has described that pilot as a first, which is Visa's own claim. If adoption is uneven, an architecture that lets you add a scheme when its first customers appear is a better fit than one that bets on all of them at once.
A sequence for the first ninety days
For a team starting now, a measured order of work looks like this. It is a suggestion rather than a method.
- Define the mandate object first. Write it down with the product, risk and legal teams. Include ceiling, scope, expiry, conditions and confirmation rules, and agree how revocation works.
- Build the event model next. Decide the canonical events and what each downstream team needs to read.
- Implement one adapter end to end. Pick the scheme your customers or acquirers are most likely to present first, and use its sandbox to stress your model.
- Add the identity abstraction with two verification methods stubbed. The aim is to prove the interface can take a second method without change.
- Review the model after the second scheme, not before. Expect to change it, and track which changes touched the core and which stayed in adapters.
The measure of success is how many components change when you add the next scheme.
Where Innovify fits
Innovify is a technology partner with deep expertise in banking, financial services, fintech and insurance, and agentic commerce and payments is one of our specialist areas. The architecture described here is the kind of work we do with product and engineering leaders: modelling mandates and events with risk and compliance in the room, building the first adapters and keeping the core stable as schemes change. We design compliance in from day one, because the audit trail is easier to build into the model than to bolt on afterwards. We build for regulated clients rather than being a regulated firm ourselves.
As an implementation partner across multiple fintech platforms, we help brands find a fast, compliant route to launching financial products. If you would like to test an architecture against real scheme sandboxes before committing, Innovify AI Labs lets enterprise teams run several proofs of concept in parallel, test with real users and finish with a business case ready for funding.
FAQ
What is a protocol-agnostic architecture for agentic checkout?
A protocol-agnostic architecture keeps your core system in your own terms and treats each payment standard as an adapter at the edge. The core models agent identity, mandate, tokenised payment instrument and settlement events. Each scheme is translated into and out of those objects, so adding or removing a scheme does not require rebuilding the core.
Which agent payment standard should we choose?
You may not need to choose yet. Reporting in October showed several approaches launching at once, including Mastercard's Agent Pay for Machines, American Express's Intent Intelligence framework and Google's Universal Commerce Protocol, with no sign of convergence. Our synthesis, which carries medium confidence, is that fragmentation is widening. Build so that the choice is reversible, and add schemes as your customers' agents present them.
What is a mandate in agent payments?
A mandate is the record of what an agent has been authorised to do on a customer's behalf. It typically covers the scope, the spending ceiling, the validity period, any conditions and whether human confirmation is required. Each scheme represents this differently, so we recommend holding a single canonical mandate and translating schemes into it.
How much does protocol-agnostic design add to build time?
It adds design effort up front and should reduce rework later, but we do not have evidence on the size of either, so we will not quote a figure. The extra effort is mostly in defining the mandate and event models and keeping adapters separate. The test of whether it has been worth it is how few components change when you add a second scheme.
How does this relate to FCA expectations?
The FCA has indicated that it is applying existing frameworks, including Consumer Duty and senior-manager accountability, to AI rather than writing new rules for agents. A canonical mandate and event history help you show who authorised a transaction and what followed, whichever protocol was used. This is general context rather than legal advice.
Conclusion
Agent payment standards are multiplying, and no network or platform is displacing the others. Choosing a winner is a bet most teams do not need to make. A four-layer core of identity, mandate, tokenised instrument and settlement events, with each protocol confined to an adapter, lets you support several schemes and absorb change locally. Build the mandate and the event model first, prove them against a second scheme, and measure success by how little changes when the next standard arrives.
