When AI Becomes the Buyer: Payment Testing for Agentic Commerce

The agent finds a product, chooses a seller, and moves into checkout. The card is authorized, the order appears to go through, and the customer receives a confirmation.

But what if shipping pushed the total above €140? What if the agent selected the wrong product variant? What if the customer's banking app showed the payment as completed while the merchant still displayed it as pending? Or the agent saw a timeout, tried again, and the customer ended up with two orders?

These are familiar payment-quality failures with a new participant in the journey: software that can interpret instructions, make decisions, and act on the customer's behalf.

The Payment Rails Are Familiar. The Buyer Is Changing.

Agentic commerce is still developing, and there is no single industry model for how autonomous purchasing will work.

Visa is building mechanisms to help merchants identify trusted commerce agents. Mastercard has introduced Verifiable Intent to create stronger evidence around what a consumer authorized. Stripe has introduced scoped payment tokens for agent-driven purchases. OpenAI's Agentic Commerce Protocol separates the agent experience from the merchant's existing payment processing.

The details will continue to evolve. What is already becoming clear is that part of the shopping journey can move away from direct human interaction.

Traditionally, a customer searches, compares, chooses a product, selects a payment method, authenticates, and confirms the purchase themselves.

An agent may perform some of those steps instead.

The customer might say: “Buy this if it stays below €100.” or: “Find the cheapest direct flight arriving before 6 p.m., but don't book basic economy.”

The agent now has to interpret that instruction, find a suitable product, understand the current price and conditions, decide whether the purchase remains within the user's boundaries, and then move into a payment journey that may still involve cards, wallets, bank redirects, authentication challenges, and local payment methods.

The underlying payment infrastructure has not disappeared.

What has changed is the path into it. For quality teams, I think the journey becomes: user intent → agent decision → checkout → real payment method → authentication → payment outcome → agent interpretation → customer-visible result

Every transition creates somewhere the experience can go wrong.

Start Testing Before the Payment Screen

Consider the flight example.

The agent finds a fare for €180. The user asked for the cheapest direct flight, arriving before 6 p.m., with no basic economy.

The payment itself may work perfectly. That does not mean the purchase was correct.

Did the agent understand “direct” properly? Did it choose the correct fare class? Did baggage or seat restrictions matter? Did taxes increase the price after selection? Was the fare still available when checkout started?

Agentic payment quality therefore starts before card authorization. Teams need scenarios where price, inventory, delivery costs, taxes, or product conditions change between discovery and checkout.

Suppose an item is displayed at €129 when the agent finds it, but the total becomes €148 after delivery and tax.

• Does the agent continue because the product price was below €140?
• Does it stop because the final amount exceeds the customer's stated limit?
• Does it return to the customer for approval?

The important outcome is whether the system respects the customer's actual intent when commerce conditions change.

Then Test the Real Payment Journey

This is where established payment-testing practice remains critical. An AI agent does not make cards, wallets, bank accounts, issuer behavior, or local payment methods suddenly predictable.

A customer may still need to authenticate through 3DS. A banking app may open. A wallet may require biometric confirmation. A local payment method may redirect the customer away from checkout and then back again.

And those experiences vary by market, device, issuer, OS version, network condition, payment method, and account. That is why real-world payment testing matters.

Testlio's public payments approach emphasizes testing with real devices, real payment methods, real transactions, and in-market expertise where appropriate. That becomes particularly useful in agentic journeys because the AI layer still has to survive everything that happens when a real customer reaches the financial part of the transaction.

Imagine an agent starts a purchase and the issuer requires 3DS.

The customer receives the authentication challenge on their phone.

What should happen next?

The agent needs to pause rather than assume failure. The checkout needs to preserve the correct state. The customer needs to complete authentication. The flow then needs to resume the same transaction.

Now test what happens when the customer cancels the challenge.

Or the banking app does not return correctly.

Or authentication succeeds but the merchant page still shows “processing.”

Or the bank shows the payment while the agent tells the customer it failed.

Those are exactly the kinds of problems that are difficult to understand from an API response alone.

The Agent Has to Understand Payment Failure Too

Payment testing is not only about successful transactions. Declines, abandoned authentication, insufficient funds, expired cards, unavailable payment methods, pending states, and redirects are normal parts of real commerce. An agent needs to interpret those states correctly.

Suppose the issuer declines a transaction because additional authentication is required.

• Does the agent understand that the customer needs to take an action?
• Or does it simply try the card again?
• Could it switch to another stored payment method without the customer expecting that?
• What happens if the customer says, “Try again,” after the original transaction has actually succeeded but the confirmation was delayed?

The customer-facing outcome matters. A crowd tester may not see the underlying issuer response code, orchestration rule, or idempotency key. But they can see something equally important: whether one intended purchase became one order, whether the customer was charged once, and whether the system told them the truth about what happened.

Be Deliberately Difficult With Interrupted Journeys

Payment systems live in an imperfect world.

Connections drop, apps move into the background, bank redirects take time, webhooks arrive late, customers press buttons twice and agents retry.

An agentic journey introduces another piece of software capable of deciding that something has failed and attempting to recover. That makes interruption testing especially important.

• Start a payment and lose connectivity before confirmation.
• Complete authentication but close the merchant app before returning.
• Allow the bank to approve the payment while the checkout remains stuck in a loading state.
• Resume the agent conversation after several minutes.

Then ask simple questions:

1. Did the customer get one order or two?
2. Does the agent understand that the payment already happened?
3. Does the merchant show the same outcome as the banking app?
4. Can the customer safely continue from where they left off?

The underlying cause might be retry logic, an orchestration issue, a delayed callback, or an idempotency failure. Crowd testing may not diagnose that root cause directly. But it can expose the real customer-visible symptom and collect the evidence engineering teams need to investigate it.

Global Payments Are Still Local to the User

Agentic commerce does not flatten regional payment behavior. A journey that works with a US credit card on desktop Chrome may behave very differently with a European bank redirect, a local wallet, a different currency, or a mobile banking app. The agent may begin the journey in one interface, but the transaction can quickly move across other apps and services.

This is where distributed, in-market testing becomes especially valuable.

A tester in the target country can use the payment instruments, banking apps, networks, devices, and authentication patterns that real customers use.

That allows teams to validate questions such as:

• Does the correct currency remain visible throughout the journey?
• Are taxes, fees, delivery charges, and the final amount consistent?
• Does a local payment method appear when expected?
• Does authentication work on the tester's actual device?
• Does the bank redirect return to the correct checkout state?
• Does the agent correctly understand a pending, failed, cancelled, or completed payment?
• Does the customer receive the right confirmation after returning from an external banking or wallet flow?

A sandbox remains useful for repeatable scenarios and controlled failures. It should not be assumed to reproduce every issuer decision, bank-app handoff, wallet interaction, or real-device condition. Agentic commerce makes that gap more important.

The Payment Response Is Not the Whole Truth

One of the most useful lessons in payment testing is that different systems can disagree about what happened.

• The bank might show the payment as completed.
• The merchant might show the order as pending.
• The customer might receive no confirmation.
• And now the agent might say, “Your purchase failed.”

Which one does the customer believe?

Testlio's Solidgate case study provides a useful conventional example of why end-to-end validation matters. During live, in-market testing, an issue was found where a product was delivered before payment had actually been confirmed.

The important lesson is not the specific defect. It is that payment quality cannot be inferred from one technical response. With an agent in the journey, there is now another state to validate: what the agent believes happened.

A Practical Way to Structure the Testing

I would not create an entirely new payment-testing discipline for agentic commerce.

I would extend established payment testing across four connected areas.

• Agent behaviour: Does the agent correctly understand the user's instruction, product constraints, amount limits, and approval boundaries?
• Real payment journey: Does the customer successfully move through payment-method selection, real authentication, redirects, approval, failure, cancellation, and recovery?
• Real-world conditions: Does the experience hold up across target countries, currencies, devices, OS versions, networks, issuers, wallets, cards, bank-based methods, and local payment options?
• Customer-visible outcome: Do the agent, merchant, payment experience, and resulting order tell a consistent story about what actually happened?

Some failures will originate deeper in the payment stack, in orchestration, token handling, callbacks, fraud controls, or retry logic. Those areas may require engineering-supported testing and backend telemetry to diagnose properly.

The crowd's role is different and complementary: validate whether all of that infrastructure produces the correct experience for a real customer, using the payment methods and conditions that customer would actually encounter.

What Quality Teams Should Prepare for Next

Agentic commerce will change shape several times before common patterns settle.

We should be careful not to pretend we already know how autonomous purchasing will work in every market or how much control consumers will eventually delegate.

But quality teams do not need to wait for that certainty.

The important questions already exist:

• What did the customer ask for?
• What did the agent decide to do?
• Did the real payment journey behave correctly?
• Did authentication, failure, and recovery preserve the customer's intent?
• Did every customer-visible part of the experience agree on the outcome?

Good payment testing has always followed the money through the real transaction and the experience around it. Agentic commerce adds one more thing that deserves the same attention: the decision that caused the money to move.