Open Payments Protocol AP2: 9 Things Coming in 2026

Last quarter one of our merchant clients watched an AI agent add three items to a cart, navigate a promo code, and then stall at the exact moment it needed to authorize a charge. Everything upstream worked. The product feed was machine readable, the manifest validated cleanly, the agent understood inventory and pricing. Then the checkout asked for a card, and the agent had no protocol-native way to say “I am acting on behalf of a human who has already agreed to spend up to this amount for this purpose.” The transaction died in the last ten percent. That gap, the missing trust and authorization layer between an autonomous agent and a real payment, is exactly what the open payments protocol AP2 is built to close, and it is the single most consequential piece of infrastructure landing in agentic commerce right now.

We build UCP infrastructure for a living, so we have watched the payments question move from a theoretical footnote to the thing that actually blocks live transactions. You can have a perfectly conformant catalog and still lose the sale because nothing tells the payment network that this agent is authorized, that the mandate is valid, and that a specific human stands behind it. AP2, Google’s Agent Payments Protocol, is the emerging open standard for that mandate and authorization layer, and it slots directly beneath the commerce protocols we work with every day. This article is our honest read on what AP2 is, why it matters, and the nine specific shifts we expect it to drive across merchant stacks in 2026.

TL;DR

What AP2 actually is: The open payments protocol AP2 is Google’s Agent Payments Protocol, a vendor-neutral standard for cryptographically signed mandates that prove an AI agent has authority to spend a human’s money within defined limits, sitting as the trust layer beneath commerce protocols like UCP and ACP.
Why it matters now: Catalog and checkout readiness is no longer the bottleneck; authorization is. Without a mandate protocol, agents complete discovery and cart building but stall at payment authorization, and AP2 is the first serious open answer to that gap.
What to do about it: Treat AP2 as a payments-layer requirement, not a payments-provider feature. Merchants who separate their commerce manifest from their mandate handling, log every mandate, and test agent-initiated checkout end to end will be positioned to capture agent-driven revenue before competitors even notice the shift.

What an Open Payments Protocol Actually Solves

Before the list, we need to be precise about the problem, because most coverage of AP2 skips it. Traditional online payments assume a human is present at the moment of authorization. You see a checkout, you enter a card, you approve a bank prompt, and the payment network treats your presence as the proof of intent. Every fraud model, every 3D Secure flow, every chargeback rule is built on that assumption of a live human at the keyboard.

Agentic commerce breaks that assumption completely. When an AI agent shops on your behalf, the human is not present at the transaction moment. They may have expressed intent hours earlier (“book me a flight under 400 dollars next Tuesday”) and then walked away. The payment network now faces a question it was never designed to answer: is this agent authorized, and by whom, and for how much? An open payments protocol like AP2 exists to answer that question in a standard, verifiable, cross-vendor way. That is the whole game.

Now to the nine shifts we expect, ordered by how much they will actually move revenue and risk for merchants.

1. Mandate-Based Authorization Becomes the New Default

The core innovation of the open payments protocol AP2 is the mandate. A mandate is a signed, structured object that says, in effect, “this agent is authorized to spend up to this amount, for this category of purchase, within this time window, on behalf of this verified human.” Instead of the agent presenting raw card details, it presents proof of delegated authority, and the payment side can verify that proof cryptographically.

We expect mandate-based authorization to become the default expectation for any agent-initiated payment within the next eighteen months. This is a structural change, not a feature toggle. In our experience helping merchants prepare their stacks, the teams that internalize this early stop asking “how do we let agents use a card” and start asking “how do we verify the mandate behind an agent’s request.” Those are very different engineering problems, and the second one is the one that scales.

Best for: merchants who already see meaningful agent traffic in discovery but lose it at checkout. Mandate handling is the piece that recovers that lost last ten percent.

The practical implication is that your payment integration needs a place to receive, validate, and log a mandate object separate from your existing card flow. Treat the mandate as a first-class artifact. It is the thing that will settle disputes, satisfy auditors, and, frankly, keep you out of trouble when an agent charge is contested.

2. Two Mandate Types Split Intent From Execution

AP2’s design distinguishes between what we describe to clients as intent mandates and cart mandates, and understanding the split is essential. An intent mandate captures the human’s higher-level authorization, the standing instruction, before the specific purchase is known. A cart mandate captures the concrete transaction, the exact items, prices, and totals, at the moment of execution.

Why does this matter? Because it maps cleanly onto how agents actually behave. A shopper tells an agent to “restock my usual coffee when I run low, up to 60 dollars a month.” That is an intent mandate: broad, time-bounded, category-scoped. Weeks later the agent finds the coffee, builds a cart, and generates a cart mandate for the specific 42-dollar order. The payment network can verify that the cart mandate falls within the bounds of the intent mandate, and only then authorize.

Standout feature: this two-tier model is what makes genuinely autonomous, delayed, or recurring agent purchases possible without a human re-approving every single charge. It is also what makes them auditable, because every cart mandate traces back to a specific intent mandate and a specific verified human.

We have found that merchants who model these two mandate types explicitly in their systems, rather than collapsing everything into a single “the agent said yes” event, end up with far cleaner dispute handling. When a customer says “I never authorized that,” you can produce the intent mandate that scoped it and the cart mandate that executed it. That is a defensible position; a vague log entry is not.

3. Payment-Method Neutrality Becomes a Real Advantage

One reason AP2 is called an open protocol is that it deliberately does not pick a winner among payment methods. The specification is designed to work across cards, bank transfers, and newer rails including stablecoins and account-to-account payments, without forcing merchants or agents to commit to one. The mandate proves authority; the settlement method is a separate, pluggable concern.

For merchants, this neutrality is a genuine strategic advantage rather than a technicality. It means the authorization logic you build against the open payments protocol AP2 does not have to be rebuilt every time a new payment rail matters. In our work we have watched merchants sink enormous effort into payment integrations that were tightly coupled to one provider’s assumptions, and then have to redo everything when the market shifted. A neutral mandate layer decouples the “is this authorized” question from the “how does money actually move” question, and that decoupling is worth building for on its own.

Best for: any merchant selling internationally or across customer segments with different payment preferences, where locking into a single rail is a liability.

Our take is that payment-method neutrality is one of the most underrated aspects of the whole protocol. The teams that treat their mandate handling as rail-agnostic from day one will adapt to whatever settlement mix wins, while teams that hard-code today’s assumptions will pay for it in rework.

4. Cryptographic Non-Repudiation Rewrites Dispute Handling

In a mandate-based world, every authorization carries a cryptographic signature. That signature is what gives the transaction non-repudiation, the property that a party cannot later credibly deny having authorized something. This is a meaningful upgrade over the current agentic reality, where “the agent decided to buy it” is a genuinely hard thing to prove or disprove.

We expect this to reshape dispute and chargeback handling substantially. Today, when a purchase is contested, the merchant is often at an evidentiary disadvantage, especially for anything unusual. With signed mandates, the evidence trail is built in: here is the verified human, here is the intent they authorized, here is the cart mandate that executed within those bounds, and here is the signature. That is a materially stronger position in a dispute than a screenshot of a chat log.

What this achieves: it shifts the burden of proof toward whoever is actually being dishonest, rather than defaulting against the merchant. That alone justifies serious attention to mandate logging.

The operational caveat we give every client is this: signatures are only as good as your logging. If you receive and validate a mandate but do not durably store it, you have thrown away the exact evidence that protects you. Persist mandates with the same discipline you apply to payment records, because in an agentic dispute they are the payment record’s most important companion.

5. The Payments Layer Separates Cleanly From the Commerce Layer

Here is where AP2 connects to the broader stack we build against every day. The commerce protocols, UCP among them, handle discovery, product data, cart construction, and the merchant-facing conversation. AP2 handles the trust and payment authorization underneath. The clean separation between these layers is, in our opinion, the single most important architectural insight for merchants to grasp.

We tell clients to picture two distinct concerns. The commerce layer answers “what is being bought and from whom,” and this is where your machine-readable catalog, your manifest, and your agentic checkout endpoints live. If you want the full picture of that layer, our team’s breakdown in What Is UCP: The Definitive Guide 2026 walks through it end to end. The payments layer, where AP2 operates, answers the separate question of “who authorized this money to move, and within what limits.” Confusing the two is the most common architecture mistake we see.

What this achieves: keeping these layers distinct means you can evolve your commerce readiness and your payment authorization independently, so a change in payment rails does not force a rebuild of your catalog, and a catalog update does not touch your mandate logic.

This separation also explains why a store can look ready on paper and still fail in practice. UCP Checker, which independently monitors more than 21,405 storefronts, reports that roughly 77 percent of the stores it tracks pass full UCP validation, which is 16,376 verified storefronts. That number skews heavily toward Shopify and should not be read as 77 percent of all ecommerce, and more importantly a conformant UCP manifest is not the same as an agent being able to complete a real checkout. The manifest is the commerce layer. The payment authorization is the AP2 layer. Passing one says nothing about the other, which is precisely why we keep hammering the distinction.

6. Agent Identity and Verification Get Standardized

An open payments protocol only works if you can trust the identity of the agent presenting the mandate, and if the agent can trust that it is talking to a legitimate merchant. AP2 leans on standardized identity and verification mechanisms so that both sides of an agent transaction can establish who they are dealing with before any money is on the line.

We expect agent identity verification to become a routine part of the merchant onboarding conversation, in the same way that payment gateway setup is today. In practice this means your systems will need to recognize verified agent identities, distinguish them from unverified or spoofed requests, and apply different trust levels accordingly. An agent from a known, verified platform carrying a valid mandate is a very different risk profile from an unidentified request claiming to have authority.

The last ten percent of an agent transaction, the authorization, is now where sales are won or lost; the merchants who treat the mandate as a first-class artifact rather than an afterthought are the ones who will actually get paid.

That pull-quote captures what we keep coming back to with clients. When we built early agentic checkout flows, the discovery and cart work was the easy part and the authorization was where everything got real. Identity verification is what makes authorization trustworthy at scale, and standardizing it across vendors is one of the strongest arguments for an open protocol over a proprietary one.

Best for: merchants who worry about agent-driven fraud, which is nearly all of them once they think it through. Standardized identity is the foundation that makes the rest of the fraud model tractable.

7. Open Governance Becomes a Competitive Moat, Not a Nicety

Why is AP2 called an open protocol, and why does it matter that it is? Because the specification is developed in the open, with input from many payment networks, financial institutions, and technology companies, rather than being controlled by a single vendor who can change terms unilaterally. That openness is not a philosophical preference; it is a practical hedge against lock-in.

We have argued this point at length in our writing on why open source wins in the age of agentic commerce, and AP2 is a clean example of the thesis. A payment authorization layer touches your most sensitive operations. If that layer is owned by one company that can revise pricing, terms, or access at will, you have handed enormous leverage to a single counterparty. An open, multi-stakeholder protocol distributes that control and gives merchants durable ground to build on.

What this achieves: building against an open payments protocol means the standard is unlikely to be yanked out from under you or repriced overnight, because no single party has the authority to do that. That predictability is worth real money over a multi-year horizon.

Our take is that open governance will prove to be a competitive moat for merchants who choose it, not because it is ideologically nicer but because it lowers the long-run risk and cost of the payments layer. The same logic that made us bet on open commerce protocols applies with even more force to payments, where the stakes of lock-in are higher.

8. Recurring and Delegated Purchases Finally Work Cleanly

One of the most concrete near-term wins from the open payments protocol AP2 is that it makes recurring and delegated agent purchases work without constant human re-approval, while keeping them safe. This is where the intent-mandate model from earlier pays off in the real world.

Think about the categories where standing authorization genuinely helps: household replenishment, business supply reordering, subscription top-ups, price-triggered purchases. Today these are either fully manual or handled by brittle, provider-specific automations that break easily and offer weak audit trails. With mandate-based authorization, an agent can act on a standing intent, generate a compliant cart mandate for each specific order, and execute, all within limits the human set once and can revoke at any time.

Standout feature: revocability with a full audit trail. A human can pull an intent mandate at any moment, and every purchase made under it remains traceable. That combination, autonomy plus control, is what current recurring-payment systems do poorly.

We think this unlocks a class of commerce that has been theoretically possible but practically painful. The merchants who structure their offerings around delegated, agent-executed replenishment, and who model the mandate lifecycle properly, will capture repeat revenue that competitors leave on the table because their payment layer cannot handle delegated authority safely. Our analysis of what happens when AI agents become the primary shoppers goes deeper on how this reshapes the customer relationship.

9. AP2 and Commerce Protocols Converge Into One Coherent Stack

The final shift we expect is convergence. Right now merchants are tracking several moving pieces: UCP, ACP, and AP2, among others, and it is easy to treat them as competing or confusing. Our view is that they are complementary layers of a single emerging stack, and by late 2026 the coherent picture will be much clearer than the fragmented one many merchants hold today.

The mental model we use with clients is a layered one. Commerce protocols handle discovery and checkout mechanics; the open payments protocol AP2 handles authorization and settlement trust; identity standards underpin both. If you want to reason about how the commerce protocols relate to each other specifically, our comparison in UCP vs ACP: which standard will rule the agentic web and the merchant-focused walkthrough in OpenAI ACP vs UCP both frame the choices without the hype.

What this achieves: seeing the stack as layered rather than competing means you can adopt each layer at the pace it matures, without paralysis. You do not have to wait for a single winner to emerge before you make progress, because the layers are designed to interoperate.

We would rather merchants build toward this converged picture deliberately than react to each announcement as if it invalidated the last. The teams that hold the layered model in their heads make calmer, better decisions, and they are not thrown by every new protocol headline.

Checklist for reading the shift correctly:

Mandate as artifact: Treat every mandate as a durable, first-class record, stored with the same rigor as a payment.
Two-tier modeling: Represent intent mandates and cart mandates as distinct objects, never collapsed into one event.
Rail neutrality: Keep authorization logic independent of any single settlement method or provider.
Layer separation: Keep your commerce manifest and your payment authorization as separate, independently evolvable concerns.
Identity awareness: Distinguish verified agent identities from unverified requests and apply trust levels accordingly.
Open governance preference: Favor open, multi-stakeholder standards for anything touching payment authority.

The Agent-Ready Payments Framework: How We Prepare Merchants

Across our implementations we have distilled preparation into a four-step framework we use with every merchant approaching agent-initiated payments. It is deliberately sequential, because skipping steps is where teams get hurt.

Step one, separate your layers. What this achieves: it prevents the single most expensive architecture mistake by ensuring your commerce readiness and your payment authorization never become entangled. Audit your current stack and draw a hard line between the manifest and checkout endpoints on one side and any mandate or authorization handling on the other. If those two concerns share code paths today, untangle them before you do anything else.

Step two, model the mandate lifecycle. What this achieves: it gives you a durable, auditable record for every agent transaction from standing intent through specific execution. Define, in your data model, what an intent mandate and a cart mandate look like, how they link, how they expire, and how they get revoked. Build storage for both before you build any live flow, because retrofitting logging after the fact means losing the exact evidence you will eventually need.

Step three, wire identity and verification. What this achieves: it lets you trust the agents you transact with and reject the ones you cannot verify, which is the foundation of your fraud posture. Implement recognition of verified agent identities, decide your trust tiers, and default to conservative limits for anything unverified. Start strict; loosen deliberately as you gain confidence.

Step four, test the last ten percent end to end. What this achieves: it surfaces the authorization failures that only appear when a real agent actually tries to pay, the exact failure that killed our client’s transaction in the introduction. Run full agent-initiated checkouts through your staging environment, from discovery to signed authorization to settlement, and treat any stall at the payment step as a release blocker, not a nice-to-fix.

Framework checklist:

Layer audit complete: Commerce and payment concerns provably separated in code and data.
Mandate model live: Intent and cart mandates defined, linked, stored, and revocable.
Identity tiers set: Verified and unverified agents handled with distinct, documented trust levels.
End-to-end test passing: A real agent-initiated checkout completes authorization in staging.
Logging durable: Every mandate persisted with payment-grade retention and access controls.

Where This Fits Your Roadmap: Build the Payments Layer With Us

If you are reading this and realizing your agentic checkout stalls exactly where our client’s did, at authorization, that is the signal to act. We build the full Universal Commerce Protocol layer for merchants and design the payments and mandate handling to slot in cleanly beneath it, so your store is not just discoverable by agents but actually able to get paid by them safely. The gap between a validated manifest and a completed agent transaction is precisely the gap we close.

Our team would rather help you architect the layer separation and mandate lifecycle correctly the first time than watch you retrofit it under pressure after agent traffic arrives. If you want a concrete assessment of where your stack sits today and what the open payments protocol AP2 shift means for your specific setup, talk to us through the UCPhub contact page or start from the UCPhub platform overview. We ship this work every week, and we would rather you were ready early than scrambling late.

Measuring Success: 30, 60, and 90 Day Outcomes

We hold ourselves and our clients to concrete milestones rather than vague readiness. Here is how we structure the first ninety days of payments-layer preparation, expressed as outcomes you can actually verify.

By day 30:

Layer separation audited: Your commerce and payment authorization concerns are documented as distinct, with any shared code paths identified and flagged for untangling.
Mandate model drafted: Intent and cart mandate data structures exist on paper and in your schema, even if no live flow uses them yet.
Baseline captured: You have measured your current agent-transaction stall rate at the authorization step, so you have a number to improve against.

By day 60:

Mandate storage live: Intent and cart mandates are being persisted durably in staging, with revocation and expiry logic exercised in tests.
Identity tiers implemented: Verified and unverified agent handling is coded, with conservative default limits for anything unverified.
First end-to-end pass: At least one full agent-initiated checkout completes authorization in staging without stalling.

By day 90:

Authorization stall rate down: The day-30 baseline stall rate has measurably dropped, ideally toward the low single digits in staging.
Dispute evidence trail proven: You can produce, for any test transaction, the linked intent mandate, cart mandate, and signature that authorize it.
Rail-neutral confirmed: Your authorization logic has been tested against at least two settlement methods without code changes to the mandate layer.
Production readiness reviewed: A go or no-go decision on live agent-initiated payments is made against these documented outcomes, not against a gut feeling.

If those numbers feel demanding, that is intentional. The merchants who hit them will be transacting with agents safely while others are still debating whether the shift is real.

If you are just getting started and have no agent-payment handling at all, prioritize step one and step two of the framework above everything else: separate your layers and model the mandate lifecycle, because those two decisions constrain every later choice and are the most painful to retrofit. If instead you are auditing something that already handles agent traffic, start at step four, test the last ten percent end to end, because an existing flow that has never been stress-tested at the authorization step is almost certainly hiding a stall you have not seen yet. In both cases, the fastest way to learn where you stand is to validate your commerce layer first with an open-source UCP checker so you know the manifest is not the problem before you dig into payments.

Next Steps:

Run a validation pass: Check your storefront against the commerce layer first so you can isolate payment-layer issues from manifest issues.
Draft your mandate model: Sketch the intent-mandate and cart-mandate structures for your top delegated-purchase use case this week.
Book an architecture review: Talk to our team through the UCPhub contact page about separating your commerce and payment layers before agent traffic forces the issue.

Frequently Asked Questions

What is an open payments protocol?

An open payments protocol is a publicly developed, vendor-neutral standard that defines how payment authorization and settlement information move between parties, without being controlled by any single company. The “open” part means the specification is developed transparently, often with input from many stakeholders across payment networks, financial institutions, and technology firms, and that anyone can implement it without asking permission or paying a gatekeeper.

In the specific context of agentic commerce, an open payments protocol like AP2 defines how an AI agent proves it has authority to spend a human’s money. It standardizes the format of that proof, how it is verified, and how disputes are handled, so that agents, merchants, and payment providers can all interoperate without bespoke, one-off integrations for every pairing.

The practical value is interoperability plus durability. Because the standard is open, a merchant who builds against it can trust that many agents and providers will support the same format, and that no single vendor can unilaterally change the rules or pricing out from under them. That combination is what makes an open payments protocol worth building on for the long term.

Why is AP2 called an open protocol?

AP2, Google’s Agent Payments Protocol, is called an open protocol because its specification is developed in the open with participation from a broad set of payment networks, financial institutions, and technology companies, rather than being a closed, proprietary system controlled by one firm. The design is intended to be implemented by anyone, and it deliberately avoids favoring a single payment method or a single vendor’s infrastructure.

The openness shows up concretely in the protocol’s neutrality. AP2 is designed to work across cards, bank transfers, and newer rails including stablecoins, without forcing adopters to commit to one. It also relies on standardized, verifiable identity and mandate mechanisms rather than a proprietary trust broker. Those choices are what let it function as shared infrastructure rather than a walled garden.

Our view, as a team that deliberately bets on open standards, is that the openness is the point rather than a marketing label. A payment authorization layer touches your most sensitive operations, and open governance is the hedge that keeps a single counterparty from gaining outsized leverage over how your agent transactions work. That is why we treat AP2’s openness as a genuine strategic feature, not a footnote.

What are the benefits of open payment protocols?

The first benefit is interoperability. When authorization follows an open standard, a merchant does not need a separate, custom integration for every agent platform or payment provider they encounter. They implement the standard once and interoperate broadly, which dramatically reduces the integration surface compared to a world of proprietary, point-to-point payment deals.

The second benefit is protection against lock-in and repricing. Because an open protocol is not controlled by a single vendor, no one party can unilaterally change access terms or pricing for the authorization layer. For infrastructure this sensitive and this central, that predictability has real financial value over a multi-year horizon, and it is a core reason we advise merchants to favor open standards for anything touching payment authority.

The third benefit, specific to agentic commerce, is that open payment protocols make genuinely autonomous transactions safe and auditable. Mandate-based authorization with cryptographic signatures gives you non-repudiation and a clean evidence trail, which strengthens your position in disputes and makes delegated and recurring purchases workable without a human re-approving every charge. Those are capabilities that current human-present payment models simply do not provide.

How does AP2 relate to UCP and other commerce protocols?

AP2 and commerce protocols like UCP operate at different layers of the same stack and are complementary rather than competing. Commerce protocols handle discovery, product data, cart construction, and the merchant-facing checkout mechanics, answering “what is being bought and from whom.” AP2 handles the authorization and payment trust underneath, answering “who authorized this money to move, and within what limits.”

We tell clients to picture these as stacked layers. Your machine-readable catalog and manifest live in the commerce layer; your mandate handling and authorization live in the payments layer. Keeping them cleanly separated lets each evolve independently, so a change in payment rails does not force a catalog rebuild, and a catalog update never touches your mandate logic.

This layering is also why a store can validate cleanly at the commerce layer and still fail to complete an agent purchase. A conformant manifest says the commerce layer is ready; it says nothing about whether your payment authorization can handle an agent’s mandate. Both layers have to work, and understanding that they are distinct is the first step to getting both right.

Do merchants need to replace their existing payment provider to adopt AP2?

No, and this is a common misconception we correct early. AP2 is an authorization and mandate layer, not a settlement provider. It governs how an agent proves authority to spend; it does not replace the underlying mechanism that actually moves money. Because the protocol is designed to be payment-method neutral, it is meant to sit alongside your existing settlement rails rather than displace them.

In practice, what changes is that your stack gains a new responsibility: receiving, verifying, and logging mandates before authorizing an agent-initiated charge. Your existing provider relationships and settlement mechanics can remain, while the mandate layer becomes the gate that decides whether an agent request is legitimate enough to proceed to settlement.

Our guidance is to treat this as an addition to your architecture, cleanly separated from settlement, rather than a rip-and-replace. That separation is exactly what keeps you flexible, because it means adopting AP2 does not lock you into or out of any particular payment rail, and you can change settlement providers later without touching your authorization logic.

What happens if an agent transaction is disputed under AP2?

Under a mandate-based model, a disputed transaction comes with a far stronger evidence trail than today’s agentic transactions typically do. Each authorization carries a cryptographic signature and links back through a cart mandate to an intent mandate and a verified human. So when a purchase is contested, you can produce the specific standing intent that scoped the authorization, the specific cart mandate that executed within those bounds, and the signature proving it.

This gives the transaction non-repudiation, meaning a party cannot credibly claim they never authorized something when the signed mandate says otherwise. Compared to the current situation, where “the agent decided to buy it” is genuinely hard to prove, this shifts the evidentiary balance toward whoever is actually being truthful, which materially improves the merchant’s position in a legitimate dispute.

The critical operational caveat we give every client is that this protection depends entirely on durable logging. A signature you validated but did not store is a signature you cannot produce later. Persist every mandate with payment-grade retention, because in an agentic dispute those records are the single most important piece of evidence you have.

Is AP2 production-ready for merchants right now?

Our honest read is that AP2 is real, actively developed, and directionally where the market is heading, but merchants should treat it as an emerging standard to prepare for deliberately rather than a fully settled, universally deployed system. The specification and the layered model are solid enough to design against, and we build with that assumption, but the surrounding ecosystem of agent platforms and provider support is still maturing.

That maturity gap is actually an argument for starting now rather than waiting. The preparation work that matters most, separating your commerce and payment layers, modeling the mandate lifecycle, and building durable mandate logging, is valuable regardless of exactly how the ecosystem shakes out, and it is painful to retrofit under pressure. Doing it early positions you to move quickly once support broadens.

We would rather see merchants build the foundational architecture and test the authorization path end to end than either ignore the shift or over-commit to a specific vendor’s early implementation. Prepare the layer, prove your last ten percent works in staging, and stay flexible on the pieces the ecosystem is still settling. That posture has served our clients well through every protocol transition so far.