Visa's Agent Pilot Pays Only What a Human Approved
Most of what I track in agent payments is announced, in a limited pilot, or in closed beta. On October 20, Visa, BILL and Billtrust announced something that, by their own description, is live: a pilot in which an AI agent pays supplier invoices through supplier portals, by card, and which is “currently live and processing end-to-end transactions with participating buyers.” The three companies call it the first live pilot of its kind. That is their claim, nobody outside has checked it, and no volumes came with it. Still, a live pilot with a named platform on each side of the payment is more than most rows in my agent payments tracker can show, so I want to go through what it is. The most useful part, to me, is what the agent isn’t allowed to do.
What the pilot does
BILL is the buyer-side platform here, handling accounts payable; Billtrust sits on the supplier side, in accounts receivable. According to the joint release, which reads the same on Visa’s and BILL’s sites, a BILL Payment Agent registered through Visa’s Trusted Agent Protocol and Agentic Directory uses “tokenized payment credentials and controls aligned with the buyer’s approved payment instructions” to pay supplier invoices on behalf of BILL customers. On the supplier side, Billtrust uses the same protocol to recognise and authenticate the agent and let it into the supplier portal to complete the payment. The release says this can satisfy the site protections that CAPTCHA and other bot-blocking used to provide, without a separate login for the agent.
The step being automated is a small and tedious one. BILL’s FAQ describes it: today the final payment step “often requires an employee to manually log into a supplier portal and submit payment information.”
The controls are listed on BILL’s page: a recognised and authenticated agent acting for an identified buyer, tokenized credentials instead of shared portal logins, payment controls tied to the approved instruction, a payment path tied to the specific invoice, and visibility into authorisation and completion of the payment. A day later, Visa put out a separate release on commercial payments that describes the pilot as drawing on Visa Intelligent Commerce and the Trusted Agent Protocol, and announces Visa Commercial Payment Controls, which let businesses set transaction-level limits on spend, merchant category, location and timing, available to eligible issuers in supported countries.
What none of the material gives: how many buyers or suppliers are in the pilot, any transaction count or value, which card product the tokens sit on, what happens when a payment goes wrong, and what anyone pays. I checked the PYMNTS and The Next Web write-ups for those details, and neither adds anything beyond the release.
The agent is the least important party in it
The FAQ answers the question I would have asked first. “Is the AI agent making payment decisions?” The answer: “No. The agent only executes eligible payments that have already been approved by the buyer.”
A person approves the invoice in BILL before the agent touches it. The credential is tokenized and, per the release, tied to that approved instruction and that invoice. As I read it, the record that the payment was authorised is the buyer’s approval in BILL’s workflow plus what Visa knows about the token, and the agent’s own account of what it did is not part of the evidence at all. That is the arrangement I argued for in an agent’s self-report is not evidence: the check has to come from somewhere other than the agent. Here the check is placed before the agent acts, and the agent is left with a job narrow enough that there is little for it to report.
The FAQ also says why B2B suits it: “Why are B2B payments a good use case for agentic commerce? They already operate within established approvals, controls and the buyer’s rules.” I think that is the most candid line in the announcement. Accounts payable already had a human approval step, a system of record and a counterparty with an invoice number. The agent replaces the person typing card details into a portal, and the approval stays where it was.
American Express is working toward the same shape for consumer shopping. On October 13 it published its Intent Intelligence framework, in which a Create Intent API captures what the shopper wants, the merchant and a maximum budget; the customer authenticates and approves it; and the system issues an Intent ID and a Proof of Intent Token, which the agent uses to get a digital payment credential instead of the card number. Amex says the intent then supports fraud prevention, authorisation decisions and dispute resolution downstream. The difference is status. Amex confirmed to Digital Commerce 360 that Intent Intelligence has no live integrations yet, and that the Agent Purchase Protection it outlined in April is not yet available. Amex has published a design; Visa and BILL have the same idea with transactions behind it, in a corner of payments where the approval already existed.
Why this one fits on cards
I don’t read this as contradicting my view that most agent payments won’t run on cards. I think it shows more precisely where the line falls. My example in that piece was an agent paying a data service per record, many times a day, in small amounts, with no checkout and no cardholder. A supplier invoice is the opposite on almost every count: one payment, to a known supplier, against a document, approved by a person, and, I’d expect, usually for an amount where the fixed cost of a card payment is not the deciding issue. The card system is built around the question of whether the account holder authorised the payment, and in this pilot the answer is recorded before the payment exists.
BILL’s FAQ also points at what is in it for card volume. Buyer-side platforms like BILL “could expand card-payment opportunities to suppliers that historically supported automated payments primarily through ACH or check.” Read from Visa’s side, agents here are a way to move business payments that ran on ACH and check onto cards, by removing the manual portal step that made paying by card awkward. That is the pattern I keep seeing with stablecoins too: the networks take the new thing into their own rails rather than being routed around.
Mastercard showed the stablecoin version on October 19 with Stablecoin Security, an API that combines payment and blockchain data to score fraud, scam and sanctions risk before funds move on-chain. It launches first in North America, with worldwide availability expected in 2027, and its first partners are Borderless.xyz and Keyrails. It says nothing about agents. It is, though, a card network carrying its risk layer onto the other rail, which fits with the networks co-owning OUSD. I’d hold that loosely; a risk API launch is a statement of intent, and adoption is a separate question.
Where my reading stops
It is a pilot. “First” is the companies’ word, the size is undisclosed, and I’d treat it as evidence that the design works for some BILL customers and Billtrust suppliers, not that B2B agent payments have arrived.
The economics are missing. Card acceptance has a cost for the supplier, and none of the material says what it is in this pilot or how it compares with the ACH or check payment it would replace. The supplier’s case, as BILL frames it, is faster payment and lower days sales outstanding. Whether that is worth the acceptance cost is each supplier’s own calculation, and the announcement doesn’t help with it.
So is the failure path. Nothing I read says what happens if the agent pays the wrong invoice, pays one twice, or the supplier disputes the amount. An approval controls what should be paid; on its own it doesn’t show what was paid. The buyer still has to reconcile the agent’s payments against the approvals, and in this case that should be manageable, because the AP system is already the ledger. That is the other reason B2B invoices went first. An agent buying API calls from another agent has no AP system behind it, which is why I still think the harder ledger problem sits on the stablecoin side.
What I’d watch next is whether the pilot publishes any numbers, whether the agent is ever given discretion over which approved invoices to pay and when, and whether anyone says how a mistaken agent payment gets unwound. Until then I’d file it as the clearest live example so far of how card networks want agent payments to work: a person decides, the network records the decision, and the agent carries it out.