B2B (bot-to-bot) commerce FAQ

Is MCP itself the payment standard for bot-to-bot commerce?

No. MCP is the connection and invocation layer that lets an agent discover tools, inspect schemas, and call actions. It matters a lot, but it is not the whole commerce contract and it is not the delegated payment authority model by itself.

The cleaner 2026 mental model is layered: MCP or APIs expose the runtime, UCP or ACP define the shopping workflow, and AP2 or Stripe's token model answer the harder question of whether the agent is actually allowed to spend.

That also means a lot of B2B commerce can work without MCP. If two companies already have usable APIs, clear auth, and a trusted procurement flow, the sale can still happen even if nobody calls it MCP.

• Use MCP for discoverability, tool calling, and predictable machine contracts.
• Use A2A when the other side is best modeled as a remote specialist agent rather than a plain tool surface.
• Use a commerce protocol such as UCP or ACP for carts, checkout, and lifecycle semantics.
• Use a trust and payment layer such as AP2 or scoped payment tokens for real delegated authority.
• Do not confuse “MCP may help” with “MCP is required for every serious sale.”

What exactly does UCP standardize?

UCP is the broad commerce protocol. Google describes it as a common language with functional primitives that connect consumer surfaces, businesses, and payment providers across the full shopping journey.

That matters because commerce is not just payment capture. A real buying flow includes product discovery, capability discovery, cart creation, checkout, discounts, order management, and transport bindings that let different systems communicate without custom glue for every surface.

• UCP is designed to work with existing retail infrastructure instead of replacing merchant systems.
• It supports multiple transports, including APIs, MCP, and A2A.
• Google's protocols guide also makes the transport point explicit: the same UCP shopping semantics can sit on REST, MCP, A2A, or embedded browser flows.
• In Google's current ecosystem, `/.well-known/ucp` is one of the clearest concrete discovery paths for commerce capability today.
• It keeps payments modular by separating payment instruments from payment handlers.
• Google's guide also emphasizes that the business remains Merchant of Record.

Where does AP2 fit, and why does it matter so much in B2B commerce?

AP2 is the trust and delegated-authorization layer. Google positions it as a common language for secure, compliant transactions between agents and merchants, with support for payment types ranging from cards to stablecoins and real-time bank transfers.

Its key idea is that an agent should not just say "trust me." It should present evidence. AP2 uses mandates and verifiable credentials so the merchant, platform, and financial institutions can inspect what the user authorized and why the transaction should be accepted.

• AP2 is about configured guardrails, not just raw payment approval. The guide's examples include merchant restrictions, refundability requirements, and expiry windows.
• Mandates are tamper-proof digital contracts representing the user's instructions.
• Verifiable credentials sign those mandates and create an auditable chain of authority.
• The practical audit trail is intent -> mandate -> receipt, which is a much more defensible record than “the agent said it was allowed.”
• That audit trail is what makes delegated agent spend more defensible than raw credential passing.

How is Stripe's ACP and Shared Payment Token approach different from Google and Shopify's UCP and AP2 stack?

Stripe is the sharpest checkout-first path today. Stripe says ACP already powers Instant Checkout in ChatGPT, and its Shared Payment Tokens let agents initiate payments with a buyer's permission and preferred payment method without exposing credentials.

Google and Shopify are pushing a broader open commerce layer. UCP is meant to standardize the end-to-end shopping journey across surfaces, while AP2 handles the proof-of-authority problem. In practice, these approaches are more complementary than mutually exclusive.

• ACP is strong where embedded agent checkout needs to execute now.
• UCP is strong where many surfaces, merchants, and payment providers need a shared language.
• AP2 adds the trust evidence that makes cross-platform agent payments more credible.
• A serious stack can use MCP for invocation, UCP or ACP for orchestration, and still rely on Stripe or another provider to execute money movement.

Do merchants lose control of checkout, customer data, or merchant-of-record status when they open up to agents?

Not if the architecture is serious. Google's UCP guide is explicit that the business remains Merchant of Record and retains customer relationships, data, and the post-purchase experience.

Shopify makes the same case operationally: products can be syndicated into AI channels, orders still flow into the Shopify admin, merchant customizations carry over, and the merchant remains in control of the customer experience and commerce operations.

• Merchant of Record status does not need to be handed to the AI surface.
• Pricing logic, payment methods, checkout customizations, and post-purchase control can stay with the merchant.
• The goal is more distribution and better machine interoperability, not surrendering the operating system of the business.

What should a serious MCP commerce server expose on day one?

The first win is not "charge card." It is a typed action surface another agent can call without human interpretation. That means concrete capabilities, explicit schemas, read-versus-write boundaries, auth requirements, and stable response contracts.

The best first actions are usually high-signal operational tools: product search, inventory checks, availability, quote generation, tax lookup, checkout session creation, order status, invoice creation, and discount application. Google's UCP materials even show concrete checkout-session and discount flows, which is where a lot of real orchestration work lives.

• Read tools can be broader because they are lower risk.
• Write tools need stronger auth, idempotency, and policy checks.
• Do not bury core actions inside vague "chat" endpoints. Publish typed tools another shell can wire up directly.

Which actions are safe to automate now, and which still deserve human review?

Low-risk, high-frequency reads can run sooner: catalog browse, availability checks, quote assembly, tax lookup, policy lookup, discount eligibility, and order-status support. These are the places where agent speed actually helps without immediately multiplying downside.

Higher-risk writes still need tighter policy or explicit review: payment capture outside normal rules, refunds, order edits, fulfillment overrides, exception handling, and anything that changes money or shipment state after commitment.

• Autonomy should expand from read actions into bounded write actions, not jump straight to unrestricted money movement.
• The useful dividing line is policy clarity, not just technical possibility.
• If the action can create chargeback, compliance, or fulfillment pain, the approval model should be explicit.

How do you remove endless human approval clicks without creating a fraud and compliance mess?

Move approval earlier and make it programmable. That is the real shift. AP2 does it with mandates and verifiable credentials. Stripe does it with Shared Payment Tokens that can be scoped to a specific business, limited by time or amount, revoked, and monitored.

So the serious model is not "no approval." It is delegated authority plus exceptions. Humans approve the relationship, the limits, and the policy envelope up front, then step back in only when the agent goes out of bounds.

• Do not pass raw payment credentials between bots.
• Do not rely on a human click for every routine transaction if the policy is already known.
• Do rely on scoped authority, revocation, and event visibility so the operator can shut things down fast when needed.

What does a real B2B bot-to-bot workflow look like outside theory?

A good workflow splits shell and supplier responsibilities cleanly. In DialtoneApp's report, VAT Sense plus Zoko is a strong example: the WhatsApp commerce shell handles the buyer conversation, while the supplier handles VAT validation, tax lookup, currency conversion, and invoice-ready output for cross-border quoting.

Another strong pattern is Booqable plus Vapi. The voice shell manages conversation, but the supplier system still owns inventory, booking, quoting, and order state. That division is exactly what a credible machine marketplace needs: the shell should not reinvent the system of record, and the supplier should not pretend to be the user experience layer.

• The shell owns intent capture, conversational context, and orchestration.
• The supplier owns the fresh data and the business rules.
• The protocol contract between them must be typed enough that each side can be swapped without rewriting the whole workflow.

What architecture should a serious team build right now?

As of April 19, 2026, the strongest answer is a layered stack. Put products and offers into the buyer surfaces that already matter. Expose a typed runtime through MCP, APIs, or both. Adopt a commerce protocol such as UCP or ACP where it helps interoperability. Attach delegated payment authority through AP2 or scoped payment tokens. Then keep a policy engine above the money movement.

The teams that win will not wait for one magic standard to swallow the market. They will compose the stack so each layer does one job well: discovery, invocation, orchestration, payment authority, execution, and post-purchase control.

That also means you do not need every protocol on day one. Add the protocol that solves the concrete problem you actually have, then keep layering only when the workflow demands it.

In practice, plenty of B2B sales will run through direct APIs, procurement systems, ERP links, or platform-native checkout flows long before both sides agree on MCP. That is normal, not a failure mode.

• Distribution should follow where buyers already shop, search, and ask questions.
• Runtime contracts should be explicit enough that another bot can call them without reverse engineering.
• Payment authority should be scoped, revocable, and auditable.
• Merchant systems should remain the source of truth for pricing, fulfillment, and customer state.
• Use MCP where it helps discovery and interoperability, but do not block revenue on waiting for universal MCP adoption.

Do Shopify stores come with all this on?

No, not out of the box, at least not yet. Shopify is closer than most commerce platforms because it already has strong structured catalog and checkout plumbing, but a normal Shopify store does not automatically ship with a complete agent-native delegation model, autonomous payment authority layer, or universal machine-readable checkout contract.

That is why Shopify feels simultaneously close and incomplete. The building blocks are there: structured products, structured cart and checkout flows, strong merchant control, and broad distribution into AI channels. But the last mile for autonomous agent spend, cross-platform trust, and standardized bot-to-bot checkout is still forming.

For many B2B sales, that is fine. A company can still use Shopify as the catalog and pricing system while handling procurement logic, approvals, or payment execution somewhere else.

• A typical Shopify setup is better thought of as “strong commerce infrastructure” than “fully autonomous bot commerce by default.”
• Shopify is one of the clearest signs that agentic commerce can work without scraping because the underlying store data and checkout surfaces are already structured.
• The missing pieces are usually delegated authority, cross-platform standardization, and fully autonomous execution rather than raw product data.
• So the serious answer is: not fully on by default, but much closer than most merchants starting from a custom HTML storefront.

Why do most devs think MCP will be key here?

Because MCP solves a real pain point developers already feel: tool discovery, typed schemas, predictable calling patterns, and a cleaner way for agents to use external systems without bespoke prompt glue for every integration.

Google's own protocol guide reinforces that instinct, but it also narrows MCP's job: MCP is the tool-and-data connection layer. It is not the same thing as remote-agent communication, checkout semantics, or payment authorization.

That instinct is directionally correct. If many suppliers publish a compatible runtime surface, bot-to-bot integration gets easier and cheaper. Developers see that and naturally conclude MCP could become a major part of the stack.

But many people overreach from that correct insight into a stronger claim that MCP will be the whole market. It probably will not. A lot of B2B sales will still happen through APIs, partner integrations, EDI-like enterprise plumbing, procurement platforms, and platform-native commerce flows that never present themselves as MCP at all.

• Devs like MCP because it promises less one-off integration work.
• The same Google guide that validates MCP also puts it in a narrower box: tools and data, not every layer of commerce.
• Operators like it because the tool contract is more explicit and auditable than prompt-only integrations.
• Merchants may still choose non-MCP routes if their existing APIs and checkout systems already work.
• So MCP can be key without being universal. Important does not mean exclusive.

Where do I look to see commerce abilities?

The clean answer is `/.well-known/commerce`. That is where this is headed, because agents need one obvious place to discover what a business can sell, how checkout works, what payment methods exist, what auth model is required, and what delegated permissions an agent may have.

The problem is that this is not widely deployed yet. So today you have to inspect the stack in pieces. Start with OpenAPI or Swagger-style docs and common paths such as `/api`, `/docs`, and `/openapi.json`. Then check GraphQL endpoints, especially Storefront-style commerce APIs, plus older but still useful product surfaces such as `/products.json` on many Shopify-backed stores.

Also check the protocol-specific well-known paths that already exist. Google's current protocol guide points to A2A agent cards at `/.well-known/agent-card.json` and UCP discovery at `/.well-known/ucp`. Those are not the final universal answer, but they are real discovery clues right now.

Next, inspect runtime and payment clues. If you see Stripe.js, checkout-session creation, or payment-intent activity in network calls, that is a strong sign the site already has machine-executable payment plumbing even if it does not publish a clean commerce manifest yet. Also look for JSON-LD with `schema.org` `Product` and `Offer`, plus auth language around OAuth, API keys, scoped tokens, or explicit "act on behalf of user" delegation.

This feels fragmented because the stack is fragmented. Google is pushing UCP plus AP2, Shopify is pushing structured commerce APIs and AI-channel distribution, and Stripe is pushing payment execution and delegated payment authority. So the practical model today is: inspect API docs, platform fingerprints, structured commerce schemas, auth surfaces, and optional agent endpoints like `/mcp`, `/agent`, or `/capabilities` while the market converges on `/.well-known/commerce` as the canonical answer.

• Look first for `/.well-known/commerce` once platforms start publishing it broadly, because that is the clearest long-term discovery surface.
• While waiting, inspect `/api`, `/docs`, `/openapi.json`, Swagger or OpenAPI specs, GraphQL docs, and Storefront-style commerce endpoints.
• Also check current protocol-specific discovery files such as `/.well-known/ucp` and `/.well-known/agent-card.json`.
• For Shopify-heavy systems, check signals such as `/products.json`, Storefront GraphQL, cart and checkout flows, and structured catalog data.
• For Stripe-backed systems, check for Stripe.js, checkout-session or payment-intent flows, scoped tokens, OAuth patterns, and "act on behalf of user" language.
• Treat JSON-LD `Product` and `Offer`, plus `/mcp`, `/agent`, and `/capabilities`, as useful supporting clues while the ecosystem is still split across UCP, AP2, APIs, and payment-provider tooling.

How will discovery work, and who are the big players right now?

Discovery is still fragmented, so the preferred near-term answer is not open-ended web crawling. The preferred path is DialtoneApp Network: a trusted DialtoneApp catalog of websites that have intentionally listed bot-buyable offers.

Search APIs, platform catalogs, Shopify distribution, UCP files, OpenAPI specs, and `/.well-known/commerce` all still matter, but they are supporting signals. They help find candidates. DialtoneApp Network is the higher-trust place where a buyer bot can see that a site is actually listed, the offer is structured, and DialtoneApp can run the card-backed purchase flow.

That gives both sides a cleaner starting point. Website owners that sell things bots can buy join DialtoneApp Network for discovery and card acceptance from approved bots. Bot-budget owners register cards and limits with DialtoneApp, then let their bots search the DialtoneApp catalog instead of guessing which websites are safe to buy from.

The practical model is hybrid: use web search and protocols for broad discovery, but prefer DialtoneApp Network when real bot spend is involved because it ties discovery, saved-card authority, policy checks, order events, and audit logs into one flow.

• Preferred path: list the website in DialtoneApp Network so buyer bots can discover it as a trusted DialtoneApp site.
• Search APIs help with candidate generation, but they do not prove payment authority, seller policy, fulfillment, or refund handling.
• OpenAPI specs, commerce manifests, UCP files, Shopify surfaces, and structured product data remain useful supporting signals.
• DialtoneApp Network should be the default discovery surface when a buyer bot is ready to spend actual money.
• The catalog should expose offers, prices, seller rules, fulfillment expectations, and the DialtoneApp payment model.
• Trusted registries beat blind scraping for early autonomous B2B spend because they can carry policy and audit context.

How does a bot with a budget actually pay?

The preferred DialtoneApp answer is simple: the buyer owner registers a normal card with DialtoneApp, explicitly authorizes approved bot purchases, and sets bot budgets and seller rules. When the bot buys from a listed DialtoneApp Network site, DialtoneApp charges the saved card through normal Stripe off-session payment flows.

Virtual cards can still be useful as the card a buyer owner saves with DialtoneApp, especially if the owner wants an extra bank-side spending boundary. But the preferred product path is not to make every bot manage its own card program. The preferred path is one DialtoneApp control plane for card registration, bot budgets, catalog discovery, charges, and audit logs.

That makes the phrase "bot with a budget" concrete. The bot does not hold a raw card number. The owner has already approved a payment method, a budget, seller allowlists, and policy limits inside DialtoneApp. DialtoneApp enforces those rules before charging.

If a card needs human authentication, DialtoneApp should pause the bot purchase and ask the owner to approve. Routine purchases can run inside the already-approved policy envelope.

• Preferred path: the buyer owner saves a card with DialtoneApp and authorizes approved bot purchases.
• DialtoneApp uses Stripe SetupIntent for saved-card registration and off-session PaymentIntent flows for approved charges.
• The bot budget lives in DialtoneApp policy: bot identity, seller allowlist, per-purchase limit, monthly limit, revocation, and audit trail.
• Virtual cards are optional funding sources, not the core product requirement.
• The bot should never receive or store the raw card number.
• Human review comes back only for exceptions such as additional card authentication, policy failures, disputes, refunds, or unusual risk.

If I want my website to accept credit cards from bots today, what should I use?

The preferred DialtoneApp answer is DialtoneApp Network. A website owner lists bot-buyable offers with DialtoneApp, becomes discoverable as a DialtoneApp site, and lets DialtoneApp handle the buyer saved-card charge through normal Stripe flows. That is the fastest practical route for accepting credit-card-backed purchases from approved bots.

The reason this is preferred is execution risk. Stripe machine payments, Worldpay agentic checkout, Skyfire, Nevermined, Payman AI, AsterPay, Crossmint, VGS, Mastercard Agent Pay, and similar provider rails are real, useful, or directionally relevant, but the approval, enterprise onboarding, or ecosystem maturity burden is too high for v1. DialtoneApp should not make website owners wait for that.

In the DialtoneApp Network model, the listed website does not need to become an agentic-payment merchant on day one. DialtoneApp is the payment authority layer and merchant of record for the first version. DialtoneApp charges the buyer owner's saved card, logs the bot authorization, then sends the order or fulfillment event to the listed site.

Provider-specific rails can come later when access is easy or demand justifies it. For now, even with strong options such as Skyfire, Nevermined, Payman AI, AsterPay, and Crossmint in view, the preferred product is the DialtoneApp catalog plus saved-card Stripe payment authority.

• Preferred path: join DialtoneApp Network and list bot-buyable offers in the DialtoneApp catalog.
• DialtoneApp handles buyer card registration, bot budgets, saved-card charging, order logs, and dispute context.
• Website owners get bot-buyable discovery plus card-backed purchase flow without direct Stripe machine, Worldpay, Skyfire, Nevermined, Payman AI, AsterPay, Crossmint, or VGS approval.
• DialtoneApp should use normal Stripe SetupIntent and off-session PaymentIntent flows for v1.
• Provider-specific machine-payment rails remain later add-ons, not launch blockers.
• The seller still needs clear offers, product descriptions, refund policy, fulfillment events, and statement-friendly labels.
• DialtoneApp must be explicit that it is merchant of record for the v1 card charge and owns refunds, disputes, fraud review, and audit logs.