Prerequisites
The merchant must publish an active customer deployment, enable direct checkout, and configure currency, delivery countries, shipping amount, tax terms and a payment destination. Shopify-listed products use Shopify checkout and return a supported checkout handoff instead of a native offer.Connect a custom buyer client with MCP
For clients that manage a private customer-session bearer token, use:Authorization: Bearer ... header. Use the same allowed Origin when
sending browser requests. Token expiry, deployment configuration checks,
storefront protection and buyer ownership are the same as customer HTTP and A2A.
Keep tokens in client credential storage, outside model messages. Preserve the
session to read its offers and orders later.
The endpoint uses the official MCP SDK with stateless Streamable HTTP. The
existing /api/mcp endpoint remains the public read-only catalog interface.
When checkout is disabled, new-offer and payment tools are absent. Execution
also rechecks availability. Owned status reads and cancellation remain available
for existing offers.
After the buyer approves an offer’s exact cart version, total and currency, call:
get_purchase_offers; a checkout URL or browser return does not prove payment.
Run a read-only MCP smoke test against your running build:
Discover and establish a customer session
Run an external smoke test
Against a running build containing these endpoints, from the repository root:@a2a-js/sdk 1.3.0 with A2A 1.0. It discovers
the card, obtains a customer session, sends a catalog request and checks the task
for up to two minutes. It prints the task state and artifacts without printing
the customer token. Its default request does not ask for an offer or payment.
Pushing a PR does not make these endpoints available on a deployed application.
Set A2A_ORIGIN to a merchant-allowed buyer origin when needed; otherwise the
application origin is used. If bot verification is enabled, supply a fresh
A2A_VERIFICATION_TOKEN obtained through the merchant’s existing browser
verification flow. The script does not bypass verification.
To test offer preparation, set A2A_MESSAGE to your product request, delivery
country, and buyer details, and ask the merchant to prepare an offer. This may
reserve real stock, so use a dedicated test merchant and cancel unwanted offers.
Look for a purchase-offers artifact containing ordered batch tool results.
The command never calls pay or complete automatically.
It keeps the customer token in memory, so any offers it prepares expire normally
after it exits. For explicit cancellation or payment, use your own client below
and retain its customer session.
Use your own buyer agent
Fetch/api/embed/{deploymentId}/.well-known/agent-card.json. The card advertises
the A2A JSON-RPC endpoint and customer bearer authentication. It excludes private
prompts and model settings.
Check whether a skill has the checkout tag before requesting a new offer.
When the organization disables direct checkout, the card advertises catalog
discovery only and its agents cannot prepare new offers. Existing offers can
still be read or cancelled; their customer HTTP responses include the current
checkoutEnabled boolean. A2A task metadata includes the same boolean and only
advertises creation/payment endpoints while checkout is enabled. The server
rechecks the setting before creating offers or starting payment.
Create a session with POST /api/embed/{deploymentId}/session, an Origin header,
and {} as the JSON body. Use a merchant-allowed origin or the application’s
own public origin. Keep the returned token and sessionId; send the same
Origin and Authorization: Bearer <token> on subsequent requests. Renew the
owned session using the existing session endpoint and its previous token.
messageId for
retrying the same message. Each new message creates a task in the owned customer
context; use A2A GetTask to retrieve its state. Completed tasks expose model text
and structured purchase-offer artifacts when the agent used offer tools. The agent
asks any follow-up question in its reply text; answer it with your next message.
Streaming and push notifications are not advertised. Merchant bot-verification and rate
limits also apply to external agents; supply X-Storefront-Verification when
verification is enabled.
Identify your buyer agent
Buyer agents may sign their requests with Web Bot Auth HTTP Message Signatures. SendSignature, Signature-Input (tag web-bot-auth,
covering @authority and your Signature-Agent member) and
Signature-Agent: sig1="https://your-agent.example". Publish your Ed25519 or
RSA-PSS/SHA-512 public keys at
https://your-agent.example/.well-known/http-message-signatures-directory.
Signatures must be created within the last five minutes.
The verified agent origin is recorded on each offer and order created by that
request, so the merchant can see which agent made the purchase. Unsigned
requests still work and are treated as anonymous. A signature that fails
verification returns 401. Signing identifies your agent; it does not bypass
merchant bot verification or rate limits.
Prepare and inspect offers
The agent can useprepare_purchase_offers, get_purchase_offers, and
cancel_purchase_offers. Prices and delivered totals are calculated by the
merchant service. Proposed discounts must satisfy the configured agent’s
existing pricing and margin policies. Exact purchasable variant IDs are required
when a product has active variants.
Buyer software may also use
POST /api/embed/{deploymentId}/checkout-sessions/{operation} with the same
customer session. create accepts offers[] with stable request IDs; get and
cancel accept sessionIds[]. See the generated API schema for bounds and fields.
Batches return ordered results with aggregate success and failure counts. Offers
are owned by the customer, expire after 30 minutes, and hold inventory. A customer
may hold at most ten unpaid offers. Cancel unwanted offers to release stock.
Verify signed offers
When the platform has a signing key configured (UCP_SIGNING_PRIVATE_JWK, a
P-256 private JWK with a kid), each payable offer returned over A2A, MCP or the
checkout-sessions API includes checkoutJwt. It is an ES256 JWT of the offer
terms: merchant, cart_version, UCP-style line_items and totals in minor
units, delivery_terms and expires_at. Its exp is the offer expiry.
Storefront chat does not receive it.
Verify it with the key named by its kid in signing_keys at
/.well-known/ucp on the same host:
checkout_jwt of a closed
Checkout Mandate. The merchant does not yet accept AP2 mandates at completion.
Approve and complete a purchase
Card Pay button and external checkout handoff
For an offer whosepaymentRequirements.details.cardCheckoutAvailable is true,
storefront chat displays a Pay button. External buyer agents can request the
same hosted card page after obtaining buyer approval:
pay calls reuse the same hosted checkout for that offer version.
The payment tab returning to the application is not proof of payment. Signed
webhooks trigger the existing durable payment/order service; the same service
checks abandoned checkouts once at a 31-minute deadline. An open page is expired
before stock is released. Unconfirmed provider failures keep the reservation
pending for reconciliation. Refresh the offer using get to obtain its confirmed
state and order ID. Storefront cards refresh when the conversation regains focus
and offer a manual Refresh status button.
Agent-native payment proofs
Inspect the offer’s items,deliveryTerms, paymentRequirements, delivered total,
currency, expiry and cartVersion. Obtain buyer authorization and the payment
rail’s proof. Send the proof directly to the completion endpoint; keep it out of
agent messages and tool arguments.
paymentRequestId for completion retries. A stale approval is rejected.
Successful completion returns the native order ID. Definitive payment failures
return 402. Pending confirmation freezes the offer and is recovered durably;
inspect its state before initiating any further payment. Indeterminate x402
confirmation returns payment_review_required and requires merchant
reconciliation. It does not establish a successful purchase.
Delivery configuration and fulfillment
Company Settings → Agentic Checkout configures one organization-wide currency, allowed destination countries, flat shipping charge, tax percentage or tax-inclusive pricing, and a delivery description. Offers snapshot these terms; the same calculation is used by A2A and storefront chat. There are no carrier, postcode, weight, or service-level rate rules. A delivery description is a merchant-provided statement, not a carrier ETA or a scheduled delivery. After verified payment, checkout creates a nativeagentic order in
ready_to_ship, with items, contact details, delivery address and shipping fee,
and commits the reserved stock. Agent-native proof callers must provide a usable
full shipping address when preparing the offer; the quote currently validates
the country only. Hosted card checkout additionally collects the full address.
Dispatch and delivery remain merchant-managed. The existing marketplace shipment
actions require a supported marketplace and store connection, so they do not
book shipments for native agentic orders. No fulfillment provider is integrated
by this flow: carrier quotes, courier booking, labels, tracking events, delivery
notifications and automated refund settlement remain outside its scope. A
completed checkout confirms purchase, not delivery.