Agent-to-Agent Commerce Testing: From Discovery to Checkout

Define the transaction before the protocol

Start with a realistic buyer instruction: find two replacement filters compatible with a named machine, keep the delivered total below a stated budget, and ask before purchasing. Write down the expected product, quantity, delivery constraints, and approval requirement. Keep those expectations visible throughout the test.

Use a controlled environment and synthetic customer details. A test purchase should not create a real shipment, charge, or customer message. If a later live verification is needed, agree its scope and authorization separately. Record which environment produced each result so sandbox evidence cannot be mistaken for a completed live transaction.

Discovery, offers, and the real total

Check how the agent finds the item through search, a product feed, a website, or a catalog tool. Does it distinguish sizes and variants? Does it recognize unavailable stock? Can it find the current return terms and service-area limits? A generic product title is insufficient when the buyer needs a specific fit.

Then test the offer. Compare the displayed description, machine-readable response, cart, and checkout. Verify the currency, quantity, discount eligibility, taxes, shipping, recurring charges where applicable, and final total. Include an expired promotion and a delivery address that changes the cost. An agent should request a new decision when the offer exceeds the buyer's authorized conditions.

These are proposed acceptance checks for your workflow. They need to reflect what your store actually sells and which calculations its checkout supports. Do not mark tax or shipping as verified when a test never supplied enough information to calculate them.

Keep MCP, A2A, and checkout responsibilities clear

MCP tools expose callable capabilities with defined inputs and results. Check tool discovery, required parameters, validation errors, and the returned product or cart identifiers. A tool named “create order” needs different permission checks from a catalog search.

A2A's core concepts describe Agent Cards, messages, tasks, and artifacts for communication between agents. Where your integration uses A2A, verify that the advertised capability exists, authentication works, and the receiving agent preserves the buyer's constraints. A task reaching a completed state does not by itself establish that payment settled or fulfillment started.

The Agentic Commerce Protocol addresses programmatic commerce flows, including checkout coordination. Its documentation explicitly says implementation does not automatically list products through AI platforms. Protocol support also does not guarantee payment approval, profitable sales, or a successful customer experience. Evaluate the integration you actually have, using its supported version and payment provider.

A transaction checklist worth keeping

• Discovery: The correct product, variant, availability, and restrictions reach the buyer's agent.
• Offer: The final amount and terms match the authoritative checkout, including changes after address or quantity updates.
• Approval: The user sees the concrete item and total before the action requiring consent. Rejected or absent consent prevents that action.
• Handoff: Buyer constraints, customer scope, and transaction identifiers survive each tool or agent boundary.
• Payment: Success, decline, required authentication, and cancellation produce distinct, accurate states.
• Recovery: A timeout, retry, or repeated callback does not create a duplicate order or charge.
• Confirmation: The customer-facing message agrees with the authoritative payment and order records.

Test the awkward paths

Stripe's testing documentation provides test payment scenarios, including declines and authentication flows. Use the equivalent documented sandbox cases for your processor. Keep test credentials and test payment methods separate from live transactions, and never collect real card details just to make an evaluation feel realistic.

For the filter example, introduce a timeout after the merchant accepts the order but before the buyer's agent receives the reply. On retry, check whether the integration looks up the existing outcome or creates another order. Also change availability between discovery and checkout. The agent should explain the updated offer and obtain any newly required approval.

Finally, compare the conversation, tool results, order record, and payment record. A confirmation page is useful evidence of what the buyer saw; it is not sufficient evidence of the financial outcome. Capture identifiers and timestamps so a reviewer can trace a mismatch without exposing unnecessary customer information.

Turn failures into specific retests

Report the failing step, expected behavior, observed result, and business consequence. Separate unsupported integrations from defects in supported ones. Prioritize unauthorized purchases, incorrect totals, duplicate orders, and misleading confirmations before cosmetic issues. Our AI Quality & Agent Operations service provides a starting point for scoping this work; the evaluation checklist explains how to review the resulting evidence.