Can Pay-by-Bank Work With Agentic Commerce Protocols?
Last updated on July 1, 2026
The first question is usually blunt: can a Pay-by-Bank provider connect its checkout to ChatGPT, Gemini, or Claude today and become a native payment option?
The honest answer is no, not as a universal self-serve integration.
The more useful answer is: a provider can build the checkout layer now. The assistant can prepare the cart, the merchant can lock price and inventory, the Pay-by-Bank provider can send the shopper through bank authorization, and the merchant can create the order after verified payment status.
That does not create automatic distribution inside every AI assistant. It does create a real product: an agent-ready checkout that can be used in merchant-owned assistants, demos, pilots, custom ecommerce flows, and future protocol adoption.
For the broader market overview, start with how AI commerce payments work. This article focuses on the Pay-by-Bank implementation question.
The Short Answer
| Question | Practical answer |
|---|---|
| Can Pay-by-Bank be native inside every AI assistant today? | No. Native assistant checkout is platform-gated. |
| Can a provider build an agentic Pay-by-Bank checkout now? | Yes. Use hosted checkout sessions, bank authorization, webhooks, and status APIs. |
| Does AP2 solve distribution? | No. AP2 helps prove user authorization. Distribution still depends on platforms, merchants, banks, and PSPs. |
| Does MCP solve checkout? | No. MCP is a tool interface. It can power demos or owned-agent flows, but it is not a native payment surface. |
| What should a provider sell now? | Agent-ready checkout infrastructure, not guaranteed native ChatGPT/Gemini placement. |
The sales message should not be “we can put your bank button inside ChatGPT tomorrow.” It should be “we can make your Pay-by-Bank checkout usable by agents, auditable for protocols, and ready for platform pilots.”
What The Workaround Looks Like
The near-term pattern is a custom agentic checkout on top of the provider’s existing payment API.
The agent does not move money. It prepares the transaction. The shopper still authorizes payment in the bank flow. The merchant still creates the order from verified payment state.
- AI assistant Prepares the checkout intent
- Merchant backend Locks cart, price, tax, shipping
- Pay-by-Bank provider Creates a bank authorization session
- Shopper Approves the payment in the bank flow
- Provider webhook Sends authorized, failed, or pending status
- Merchant Creates the order after verified payment
This is less flashy than a native button inside ChatGPT, but it is buildable. It also forces the right product foundations: locked cart terms, clear user approval, webhook-driven order state, refunds, and failure handling.
Why Native Distribution Is Blocked
Pay-by-Bank is not blocked because it is conceptually incompatible with AI checkout. It actually fits agentic commerce well: the assistant prepares intent, and the shopper approves the exact payment through a trusted bank flow.
The blockers are ecosystem blockers:
- assistant platforms control which checkout surfaces and payment methods are available;
- merchants need to accept the rail and reconcile it in their order systems;
- banks or payment providers need to complete authorization reliably;
- protocols need to carry consent, cart, amount, expiry, and status cleanly;
- refunds, disputes, expired sessions, and failed authorizations need boring production behavior.
So the dependency chain is not “does an LLM understand Pay-by-Bank?” It is “does the full commerce network support this payment method in a production assistant flow?”
The Protocols In Plain English
Most confusion comes from treating every protocol as if it solves the same problem. They sit at different layers.
| Layer | Examples | What it helps with |
|---|---|---|
| Assistant surface | ChatGPT, Gemini, Claude, merchant-owned agent | Where the shopper talks to the agent |
| Tool layer | MCP, app tools, custom function calling | How the agent calls external systems |
| Commerce layer | ACP, UCP-style product and checkout schemas | How product, cart, checkout, and order data move |
| Authorization layer | AP2 mandates, PSP tokens, bank authorization | How the system proves what the shopper approved |
| Payment rail | Card, wallet, Pay-by-Bank, real-time payment | How money moves |
| System of record | Shopify, BigCommerce, custom backend, OMS | Where orders, refunds, and support live |
The important sentence is this: protocol readiness is not the same as traffic. A provider can build the right objects and still wait for platform distribution.
ACP: Concrete, But Not A Universal Payment Slot
OpenAI’s Agentic Commerce Protocol is the clearest public example of in-chat commerce. It describes how product discovery, checkout sessions, and order state can move between ChatGPT and merchants. Stripe’s ACP documentation shows the payment side of that flow.
In plain English: ACP is a strong model for what agentic checkout needs. It does not mean any Pay-by-Bank provider can self-register as a native ChatGPT payment method today.
For a Pay-by-Bank provider, the useful move is to copy the shape:
- create checkout sessions programmatically;
- lock exact amount, currency, cart, expiry, and merchant identity;
- expose status and cancellation;
- receive webhooks;
- let the merchant create the order only after verified payment state.
That makes the provider easier to plug into future assistant commerce programs.
AP2: Consent Evidence, Not Distribution
Google’s Agent Payments Protocol focuses on authorization evidence. It introduces signed mandates that can prove what the user asked for and what final cart they approved.
In plain English: AP2 is about trust and proof. It helps answer “what did the shopper authorize this agent to do?”
That maps well to Pay-by-Bank because bank authorization is already a strong approval moment. A good Pay-by-Bank checkout should store the same kinds of facts AP2 cares about:
- original user intent;
- final cart snapshot;
- merchant identity;
- exact amount and currency;
- expiry window;
- bank authorization status;
- audit log of what changed.
But AP2 does not create live traffic by itself. Assistant surfaces, merchants, payment providers, banks, wallets, and commerce platforms still need production integrations.
UCP And Commerce Data
Google’s Universal Commerce Protocol work points at another layer: how commerce data and actions become available to AI experiences.
In plain English: UCP is closer to product, store, cart, and checkout readiness. It is not a magic payment rail.
For Pay-by-Bank, the relevant preparation is to make the checkout state portable:
- the cart has a stable ID;
- the merchant and seller terms are clear;
- the amount is final before authorization;
- status can be checked after the shopper leaves the assistant;
- refunds and expired sessions are represented explicitly.
This is how a hosted Pay-by-Bank checkout becomes more than a redirect page. It becomes a commerce primitive.
MCP: Good For Tools, Not A Native Buy Button
Claude’s most relevant integration path is the Model Context Protocol. MCP lets AI clients call tools and access systems.
In plain English: MCP can let an assistant create a checkout session or check payment status. It does not create a first-party checkout button in Claude.
An MCP server for a Pay-by-Bank provider could expose:
create_bank_checkout_session
get_payment_status
cancel_checkout_session
refund_paymentThat is still valuable. It can power a merchant-owned assistant, a sales demo, an internal support tool, or a pilot with a commerce team. Just do not position MCP as native distribution.
What To Build First
The practical product is an agent-ready checkout layer.
- hosted checkout sessions with locked cart, amount, currency, expiry, and merchant identity;
- bank authorization handoff through redirect, deep link, or embedded provider flow where allowed;
- idempotent webhooks for authorized, failed, pending, expired, refunded, and cancelled states;
- status polling so the assistant can report progress without guessing;
- refund APIs and clear reconciliation rules;
- signed intent and cart snapshots that can map to future AP2-style mandates;
- an MCP or app demo that shows the flow end to end.
The provider should also document what the assistant is allowed to say. For example, “payment is pending” should mean the provider returned a pending state, not that the model inferred it from the conversation.
Minimal API Surface
An agent-ready Pay-by-Bank provider needs explicit, auditable APIs:
POST /checkout-sessions
GET /checkout-sessions/{id}
POST /checkout-sessions/{id}/cancel
GET /checkout-sessions/{id}/events
POST /webhooks/payment-status
POST /refunds
GET /refunds/{id}The checkout-session request should include merchant ID, cart ID or hash, amount, currency, locale, return URL, expiry, user-visible confirmation text, and metadata for the assistant session.
The response should include a checkout session ID, authorization URL or deep link, current status, expiry, polling URL, webhook correlation ID, and a human-readable next step.
The boring detail matters: duplicate webhooks must be safe, expired sessions must be unambiguous, and the merchant must not create an order from the assistant’s memory.
How To Position It
A credible proposal to a Pay-by-Bank provider sounds like this:
Native payment-method distribution in ChatGPT, Gemini, and Claude is not broadly self-serve today. But we can build the checkout infrastructure now: agent-created sessions, bank authorization handoff, signed intent, webhooks, status APIs, refunds, merchant connectors, and a demo surface. That gives you a working agentic checkout and makes the product ready for platform pilots when the ecosystem opens.
That is a stronger position than saying “it is impossible.” It is also safer than overpromising native assistant placement.
The Standard
The agent may be conversational. The checkout cannot be fuzzy.
Every serious Pay-by-Bank agentic checkout needs the same invariants:
- the cart is explicit;
- the amount is exact;
- the shopper approval is recorded;
- the bank authorization is the payment authority;
- the merchant creates the order from verified status;
- the system can explain failures, refunds, and disputes later.
Build those pieces now. Native protocols can then become distribution channels, not the first time the product learns how agentic checkout should work.
Decision tool
Frequently Asked Questions
Not as a universal native payment method. ChatGPT commerce is controlled by OpenAI’s commerce rollout, Gemini/AP2 still depends on ecosystem adoption, and Claude exposes tool integration through MCP rather than a first-party checkout surface.
The main blocker is not the bank rail itself. It is distribution and coordination: assistant platforms must support the payment method, merchants must accept it, protocols must carry authorization evidence, and order systems must reconcile status, failures, refunds, and support.
A provider can build an agent-ready hosted checkout: session creation, locked cart terms, bank authorization handoff, webhooks, status polling, refunds, and an MCP or app demo that lets an assistant prepare the transaction while the shopper approves payment in the bank flow.
AP2 helps with consent and authorization evidence through signed mandates. It does not by itself create live distribution inside ChatGPT, Gemini, Claude, Shopify, or any bank network.
