Payment rails integration and simulation. The payment leg, tested instead of assumed.
Payment rails · Integration in progress
Why we are building it
Our agent demos end at a confirmed order. For a merchant, that is where the harder questions start: whether the payment clears, what happens when it doesn't, and how a refund finds its way back. We are wiring agent checkout to real payment rails in test so those questions get answered by a running system.
What runs end to end so far
The payment leg of a UCP checkout runs end to end. Fiserv's agentic commerce tools are integrated and running in their test environment. We have also run the paths a demo usually skips: declined payments, cancellations and refunds.
What has been harder than expected
Keeping payment state in step with the merchant's order. An approved payment, a decline and a refund each have to land on the right order, in the right state, even when the agent is the one driving the checkout. Getting that mapping right has taken more work than connecting to the rails themselves.
Where it stands
The integration is still in progress. This page describes what is running today, and the full method and results will be added when the work is finished.
How this helps our clients
When we assess a merchant's payment setup, we look past whether the processor can take an agent-initiated payment. We check whether the order system can keep payment and order state aligned through declines, cancellations and refunds, because that is where this build has shown the real work to be.