EDITORIAL ARTICLE
Visa Intelligent Commerce: Letting Merchants Recognize an Authorized Agent
Project reference · Visa ↗Card network, agent identity and credentials · Sources checked October 28, 2026. For issuers, merchants, platforms and enterprise partners; not independently tested.
A company has approved a supplier invoice, but an employee must still log in to the supplier portal, enter card information and submit payment. In a Visa, BILL and Billtrust pilot, an agent uses controlled credentials to execute an already approved payment. The case illustrates Visa’s approach: help existing card networks and merchant portals recognize and handle agents.
Visa’s position in the chain
Visa supplies a payment network and technology services connecting financial institutions, merchant acquiring systems and platforms. Issuers and other parties typically provide the actual card account and funds. Intelligent Commerce is a group of agent-commerce capabilities spanning identity and trust, credentials and controls. Trusted Agent Protocol (TAP) focuses on verifiable communication between agents and merchants. Neither is a wallet that holds a balance for every agent. See Intelligent Commerce and the TAP announcement.
Who does what in the invoice pilot?
On October 20, 2026, Visa, BILL and Billtrust announced a live pilot for participating buyers and sellers. This flow summarizes their announcement; we did not verify it independently.
BILL’s agent operates on an instruction tied to a payment the buyer has already approved. Billtrust uses TAP to recognize the agent; tokenized payment credentials are used without sharing supplier-portal login credentials. Visa says the agent does not make the payment decision; it executes eligible approved payments. See the pilot announcement and FAQ.
Recognizing an agent is not approving a payment
| Component | Problem addressed | Boundary |
|---|---|---|
| TAP | Communicate verifiable signals about agent identity and intent to a merchant | Trusted identity alone does not prove that a user approved a purchase |
| Tokenized credential | Reduce exposure of original card details and restrict use under the scheme | Issuers, networks and merchants still handle authorization, risk and disputes |
| Agent controls | Bind purchasing or payment instructions in partner solutions | Limits, applicability, revocation and responsibility depend on implementation |
| Card network | Process applicable network transactions and services | It is not the agent’s balance |
Visa notes that some capabilities are still being deployed and final features may change. A pilot does not mean every supplier portal, merchant or issuer globally supports the product. See the product page.
Business model and judgment
Visa’s established business includes network processing and related services. Agent transactions may bring its credentials, authentication and network services into new purchasing interfaces. This is analysis, not a disclosed project revenue figure or per-transaction fee. Visa developer APIs have different pricing arrangements; specific Intelligent Commerce and TAP enterprise quotes were not verified, so general API prices should not be applied to them. See developer pricing.
Visa and Mastercard Agent Pay both seek to adapt identity and existing card payments to agents. This Visa example particularly illustrates execution of a preapproved business invoice across a supplier portal. Unlike an on-chain agent wallet, it relies on an existing commercial card network and participating institutions rather than requiring stablecoins.
Accounts-payable teams and supplier-payment platforms should ask which issuers and portals participate, how approvals constrain credentials, who handles failures, duplicate payments and refunds, and whether results return to finance systems for reconciliation.
Why do card transactions need a trust layer?
Online payments often rely on a person’s browser session, login or challenge. An agent can read and submit a page, but an automated request alone does not tell a merchant whether the agent is welcome, whom it represents or whether it is searching or paying. Visa describes TAP as offering verifiable agent signals; its announcement mentions intent, consumer-identification information and optional payment information, built on standards including HTTP Message Signatures. The actual fields, verifier and access decision depend on merchants and other participants.
The buyer wants an accurate budget and invoice; BILL needs an approved instruction; Billtrust needs a recognizable agent in the supplier portal; the issuer and network still handle the card transaction. Portal recognition does not prevent an issuer declining the card, and successful card authorization does not guarantee invoice matching or accounting reconciliation.
The pilot in an accounts-payable workflow
| Stage | Responsible parties | Records that may be needed |
|---|---|---|
| Supplier invoice | Supplier and its platform | Invoice number, amount, due date and recipient |
| Buyer approval | Buyer company and accounts-payable platform | Approved amount, approver, instruction and authority |
| Portal access | BILL agent and Billtrust | Agent identity, access result and invoice association |
| Card transaction | Issuer, network and acquirer | Authorization and processing result, transaction identifier |
| Reconciliation and exceptions | Buyer and seller systems | Paid state, duplicate checks and follow-up |
This checklist interprets participant roles; it does not claim the pilot disclosed every field, refund or retry rule. The announcement says end-to-end transactions were processed between participating BILL buyers and Billtrust suppliers. It does not establish broader geographic, merchant or scale figures here.
Who investigates a failure?
Before payment, invoice amounts may change, an instruction may expire or the portal may reject the agent. After submission, timeouts, uncertain payment status or failure to match the supplier invoice are possible. Do not simply retry without checking the original transaction, as this may duplicate payment. Confirm in contracts and integration testing which transaction ID can be queried, who can cancel, refund or dispute, and when the supplier portal and buyer ledger synchronize. These are due-diligence questions, not claims that the pilot already implements all of them.