A live Visa–BILL–Billtrust pilot shows how cryptographic agent identity and scoped card payments can close a stubborn gap between approved invoices and supplier portals. The commercial question is whether removing the password step actually changes costs, fraud exposure and cash flow.
A Real Payment, but Not an Autonomous Purchasing Decision
On 20 October 2026, Visa, BILL and Billtrust announced a live pilot in which an AI agent completes previously approved supplier-invoice card payments through a supplier portal without sharing a supplier-portal login. Visa says the pilot is processing end-to-end transactions with participating BILL customers and Billtrust suppliers. That is stronger evidence than a demonstration, but not evidence of broad commercial deployment: the partners did not publish payment count, processed value, net fraud rate, authorization success rate or measured cost savings. [1–3]
This is not an agent independently choosing what a company owes. In the disclosed design, the buyer authorizes an eligible invoice inside its accounts-payable process, BILL’s registered Payment Agent executes that instruction, and Billtrust decides whether to admit the recognized agent into its supplier-facing acceptance flow. The card payment still travels through financial infrastructure. Simple work, until there is a lot of it.
The previously missing capability is not intelligence about an invoice. AP systems already ingest invoices, match purchase orders and route approvals. The difficult last step is often that supplier accounts-receivable portals require a human to sign in, respond to anti-bot controls and type payment details even when the buyer has approved the amount. Visa’s pilot replaces that fragile credential-sharing pattern with authenticated machine access. It does not abolish approvals or change the underlying debt. [1, 6–7]
The most useful way to evaluate the development is to separate three rights: a right to enter the supplier’s payment experience, a right to spend the buyer’s money, and a right to accept that payment. Those are owned by different parties. Confusing them is where the risk starts.
The Five Checks Between an Invoice and a Completed Payment
| Control layer | Who supplies the authority? | What it prevents — and does not |
|---|---|---|
| Invoice legitimacy | Buyer AP / ERP: supplier record, purchase order, receipt, approval | Stops unapproved or duplicate invoices if controls work; cannot guarantee a supplier was not impersonated. |
| Agent identity | Registered agent + Visa Trusted Agent Protocol signature | Helps distinguish a known agent from ordinary bots; does not establish that a particular $ amount was approved. |
| Execution mandate | Buyer-approved payment instruction + payment policy | Bounds recipient, amount and eligible invoice; limits require enforcement outside the language model. |
| Portal admission | Supplier / Billtrust acceptance and anti-bot policy | Allows a recognized agent to transact; supplier still decides what it will accept. |
| Payment and evidence | Tokenized card, issuer/network checks, posting and remittance records | Moves value and records status; does not guarantee delivery, correct accounting or immunity from disputes. |
Visa’s Trusted Agent Protocol uses cryptographic signatures on agent requests, allowing a merchant to validate the message against a public key. It is an identity and integrity mechanism. The separate payment instruction must still be checked against spending policy. An authentic agent is not the same thing as an authorized purchase. The agent can be known and still be wrong, which is the awkward part. [4]
This echoes the existing scope of delegated payment authority debate. Fine-grained OAuth Rich Authorization Requests already offer a general technical model for specifying payment recipient, currency and amount rather than relying on an open-ended permission to “make payments.” The IETF standard is not proof that the pilot uses that exact implementation; it illustrates why precise machine-readable mandates matter. [10]
Figure 1. A conceptual five-stage invoice-payment chain derived from the pilot disclosures. This is not a diagram of unpublished proprietary message flows.
No Supplier Password Does Not Mean No Credentials
There are at least three distinct implementations businesses should avoid conflating. First, an AP agent can fetch invoices from an authorized mailbox, EDI feed, Peppol e-invoice exchange or ERP connector, and submit them through existing controls. No supplier web portal is necessarily involved. Peppol’s BIS Billing 3.0 specifies machine-readable invoice content supporting accounting, matching and payment-related workflows. [7–8]
Second, a buyer can send a bank payment directly to a verified supplier account via an approved treasury workflow. Here the software needs permission to propose or initiate payment orders inside the payer’s financial system, not the supplier’s online password. Tools such as Modern Treasury support approval rules by amount, source and destination; some payment orders only reach the bank after the designated reviewers approve them. [11, 17]
Third, the Visa–BILL–Billtrust model automates a supplier portal that has historically expected an interactive login. The supplier-side platform must actively support trusted-agent recognition, and the buyer must provide a payment credential that is constrained to the agreed purpose. A card token is not a universal credential for any portal. Supplier participation, card acceptance and integration determine whether this particular method works. [1–3]
Stripe has separately described issuing and wallet infrastructure that can produce single-use agent credentials with amount, merchant and time controls, while keeping underlying card details outside the agent’s reach. This is analogous to the wider market for tokenized Visa credentials for AI agents, but is not the same product, partnership or acceptance policy as the BILL pilot. [9]
| Invoice-payment route | What must already exist | The main economic / control trade-off |
|---|---|---|
| Supplier-portal agent card | Participating supplier portal; approved invoice; agent identity; token/card acceptance | Removes manual login and card entry, but supplier card charges and card rules still apply. |
| ERP-to-bank ACH / SEPA credit | Verified bank details; bank or treasury integration; payment approvals | Often avoids portal login altogether; reconciliation, payee changes and fraud controls remain. |
| E-invoice + AP automation | Structured invoice feed or OCR; validated supplier and matching rules | Automates invoice handling, not necessarily the final payment rail or a supplier portal. |
| Bank/API or alternative settlement | Compatible receiver, authenticated access and suitable authorization | Potentially different speed and fee allocation; does not remove approval or verification needs. |
The Economics: Time Saved Is Not the Same as Payment Cost Saved
Consider an illustrative mid-market buyer processing 500 invoices a month at an average value of $4,000, or $2 million of invoices. Suppose one-quarter—125 invoices, worth $500,000—requires a manual supplier-portal completion step. At five minutes each, the buyer uses 10.4 hours monthly. Valuing loaded labor at $42 per hour implies roughly $438 in processing work potentially removed. That is a bounded benefit, not a finding from the pilot.
Suppose the same 125 invoices could otherwise be paid through a direct bank channel costing an illustrative $0.60 per transfer: $75 in payment charges. If routing these invoices to card acceptance instead created a hypothetical 1.9% all-in supplier acceptance expense, the supplier-side charge would be $9,500—over 21 times the modeled labor saving. A 0.8% buyer card rebate would transfer another $4,000 in economics to the buyer, but cannot by itself erase the system-wide fee. These are deliberately invented assumptions, not published Visa, BILL or Billtrust prices.
That does not imply the pilot is uneconomic. If the supplier was already receiving a commercial card, an agent might remove the manual step without adding a new acceptance fee. Or an early receipt can free working capital, improve collections and reduce exception handling. The point is that the appropriate comparison is incremental cost, not a card charge casually compared with an employee’s login time. The time gets saved, but a fee still shows up somewhere.
At a hypothetical 11% annual supplier funding cost, accelerating payment by 15 days is worth about 0.45% of the invoice value; 30 days is worth 0.90%. To offset an illustrative 1.9% card-acceptance cost by financing benefit alone would require about 63 days of acceleration. For a $4,000 invoice, the 1.9% charge is $76 and 15 days of funding value is just $18.08. That calculation excludes card rewards, procurement discounts, chargeback and credit risk, processing overhead and any negotiated pricing.
Figure 2. Original break-even calculation: funding value = days / 365 × 11% cost of capital. The 1.9% acceptance fee is a scenario input, not a market quote.
This makes buyer/supplier bargaining power central. Buyers can prefer the grace period, rewards and easier reconciliation of a card; suppliers may prefer a lower-cost credit transfer. A product that makes card payments easier can increase card volume without necessarily reducing the economy-wide cost of paying an invoice. That tension is especially relevant to investors evaluating monetization potential rather than impressive automation footage.
The Failure Mode Has Moved From Password Theft to Payment Instructions
Credential sharing is an obvious security weakness: vendor portal usernames and passwords can be copied, reused, leaked or broken when multifactor authentication changes. Cryptographic identity and tokenized payment credentials reduce this exposure. They do not verify that the invoice itself is genuine, the supplied bank account is correct or the human approved the exact outcome. The FBI identifies fake vendor invoices and updated payment instructions as standard business-email-compromise patterns. [13]
The Association for Financial Professionals’ 2026 survey found that 76% of respondent US organizations experienced attempted or actual payments fraud in 2025. That figure is an organizational survey exposure rate, not an estimate of AI-agent fraud or of losses in this pilot. It helps explain why businesses cannot treat the absence of stolen passwords as sufficient security. [12]
Five controls should be independent of the model: immutable approved-invoice IDs; verified supplier master data and out-of-band bank-detail changes; exact amount/currency/payee constraints; one-time execution and idempotency checks; and a pause/revoke mechanism with an audit log. The agent should not be able to change the destination account, then approve its own change, then send the payment. This segregation is important becuase malicious instructions in an invoice PDF or portal response could otherwise be interpreted as operational directions. OWASP flags this as an indirect prompt-injection risk. [16]
A worst-case outcome is not one random error. A compromised supplier record can affect a whole batch. In a 500-invoice, $4,000-average portfolio, a hypothetical 0.1% error rate corresponds to $2,000 of gross payment value requiring investigation on an expected-value basis. By contrast, thirty $4,000 payments routed to one compromised destination expose $120,000. Neither value is a forecast of loss: some errors may be reversed, blocked or recovered, while others may not. These numbers show how control concentration creates a disproportionate tail.
Figure 3. Hypothetical gross exposure, not measured agent fraud or expected realized loss. Rate scenarios multiply $2 million monthly invoice value; the batch scenario is 30 × $4,000.
Operational status is another source of loss. A payment marked “completed” in a treasury platform may still be subject to return on some rails. Matching authorization events to settlement, bank statements, supplier acknowledgments and invoice closures is neccessary to avoid paying twice after a timeout. Modern Treasury’s payment-order documentation explicitly distinguishes completed, returned, reversed and failed statuses. [17]
Who Actually Benefits: Buyer, Supplier, Network and Software Vendor
BILL is positioned to sell higher AP completion rates and less manual intervention to its buyer customers. Billtrust benefits when its suppliers accept more properly identified payments and receive cleaner remittance information, although any higher card costs remain a negotiation with the supplier. Visa benefits when an approved business invoice can be routed through accepted card rails and when trust infrastructure makes more supplier checkout points accessible. The business model is a coordinated handoff across firms, not an AI agent replacing all three.
The network’s October 21 announcement also introduced supplier enablement analytics and commercial fraud controls, including supplier validation and virtual-card authentication. Those adjacent offerings matter because agent identity alone cannot solve supplier onboarding or payment redirection. Visa’s commercial incentive is to support spend that can be reliably recognized, routed and accepted, with issuer, network, processor and software fees distributed across the ecosystem rather than collected by one actor. [5]
That interpretation is falsifiable. If expanded agent access does not improve card acceptance, successful payment completion or supplier cash collection enough to compensate for fees and exceptions, the commercially useful part of the technology may end up being bank-payment orchestration instead. And that is a different thing altogether, really. For a wider discussion of the payment rails competing for transaction economics, see how payment networks and fintechs monetize alternative rails.
US ACH, EU Account Verification and the Limits of Policy
The US ACH route is not standing still. Nacha’s 2026 risk-management rules expanded risk-based fraud-monitoring obligations in two phases—20 March and 19 June—including detection of entries suspected of being unauthorized or initiated under false pretenses. Those rules do not require a particular AI agent architecture or absolve counterparties of their underlying responsibilities; they make payment validation more relevant to automated originators and their service providers. [14]
In the euro area, a bank transfer has a different security checkpoint. Under the EU Instant Payments Regulation, euro-area providers were required to offer Verification of Payee for credit transfers from 9 October 2025. The service checks the account identifier against the intended recipient’s name before payer authorization; it applies to ordinary and instant credit transfers, not to every card portal transaction. A match is a risk-reduction signal, not a guarantee that the whole supplier relationship is genuine. [15]
In neither market should a business infer that a supplier portal is optional merely because a bank transfer can be initiated elsewhere. A supplier may need richer remittance, a particular payment method, or contractual evidence of discharge. Conversely, a portal’s presence is not a reason to share a password with automation software. The best route depends on the supplier’s acceptance rules, dispute rights, data quality and the payment economics.
What Would Prove the Agentic-Invoice Thesis Wrong?
Three outcomes would undermine the strongest version of the pitch. First, access only works for a small set of integrated portals while most suppliers still require human intervention. Second, measured automated completion improves but the rate of exceptions, duplicate payments or disputed transactions offsets the hours saved. Third, suppliers resist agent-initiated cards when acceptance fees exceed collection and financing gains.
The reverse would be meaningful evidence: independently reported transaction counts; the share of eligible payments completed without human touch; supplier acceptance and decline rates; per-payment cost relative to previous methods; fraud and recovery rates; and time from buyer approval to cash posting. As of the research date, the three companies have not publicly provided that performance dataset for the live pilot. Some invoices will just not fit this route, and that is fine.
The Practical Test for an AP Team
An AP lead assessing an agentic-payment vendor should demand a short, auditable chain: a source invoice or structured message; a matched supplier and approved amount; a signed agent identity; a bounded, expiring execution instruction; independent supplier admission; evidence of issuer or bank authorization; and a reconciled receipt. A service that cannot show who approved a payment, who changed vendor details and what happened after a declined or timed-out attempt is not ready for unattended execution.
Start with read-only invoice ingestion, then approval preparation, and only then bounded execution for established suppliers. Review exceptions and reserve manual intervention for first-time beneficiaries, bank-detail changes, large or irregular amounts and policy mismatches. A passwordless agent is useful when controls are stronger than the human workaround it replaces, not merely less visible.
Bottom Line
The Visa–BILL–Billtrust pilot demonstrates a narrow but real breakthrough: an authenticated machine can carry an approved invoice through a supplier-controlled portal without borrowing a person’s login. The core invention is a trustworthy link between agent identity, buyer authority, supplier acceptance and a constrained payment credential. Removing the login is valuable. But the final test is whether the same design also reduces total payment friction without merely shifting card costs or fraud risk to somebody else.
Methodology and Scope
Research is current to 12 November 2026 and prioritizes partner disclosures, security and payment standards, official platform documentation and regulator or industry-group material. Visa’s pilot is described as live only for participating buyers and suppliers; the announcement did not publish transaction volume or measured efficiency. All modeled inputs are hypothetical: 500 invoices/month, $4,000 average face value, 125 portal payments, five minutes manual effort per portal payment, $42/hour loaded labor, $0.60 bank payment charge, 1.9% card acceptance charge, 0.8% buyer rebate and 11% annual supplier cost of funds. The calculations ignore tax, float timing, partial acceptance, variable pricing, dispute cost and account-level credit terms. “Gross exposure” describes amounts needing investigation, not probability-weighted loss; the sample error rates are unobserved. This article is financial analysis, not a product endorsement, implementation manual or legal advice.
What to Measure Before Calling It a New Payments Market
A pilot can recieve positive feedback while leaving the economics unproven. Finance leaders should publish outcomes seperately for existing card-paying suppliers and suppliers converted from bank payments; otherwise acceptance-related fee changes are lost inside an average. The measures below are proposed tests, not results disclosed by the partners.
| Measure | Numerator / denominator or definition | Why the split matters |
|---|---|---|
| Portal coverage | Integrated supplier portals / portals used by buyers | Shows whether reach expands beyond a narrow launch set. |
| Touchless completion | Approved eligible invoices paid without human rescue / approved eligible invoices | Separates successful authorization from unattended execution. |
| Fee-adjusted benefit | Manual work and delays avoided, less incremental payment costs | Distinguishes card conversion from actual total-cost savings. |
| Exception intensity | Declines, duplicates, remittance mismatches and disputed payments / attempts | Measures whether automation creates new clean-up work. |
| Buyer-to-cash time | Median time from buyer approval to supplier cash posting | Tests the supplier working-capital argument with observed data. |
Sources
[1] Visa: Visa, BILL and Billtrust live pilot, 20 Oct 2026
[2] BILL Investor Relations: Joint pilot release and B2B scope, 20 Oct 2026
[3] Billtrust: Supplier-side description, 20 Oct 2026
[4] Visa Developer: Trusted Agent Protocol implementation and cryptographic signatures
[5] Visa: Commercial payments, analytics and fraud solutions, 21 Oct 2026
[6] Microsoft: Business Central Payables Agent FAQ, including limits on posting
[7] Microsoft: Dynamics 365 vendor invoice automation and receipt matching
[8] OpenPeppol: Peppol BIS Billing 3.0, May 2026 release
[9] Stripe: Issuing for agents and one-time payment credentials
[10] IETF: RFC 9396: OAuth 2.0 Rich Authorization Requests
[11] Modern Treasury: Payment order approval rules
[12] AFP: 2026 Payments Fraud and Control Survey, Apr 2026
[13] FBI: Business email compromise: vendor-invoice impersonation
[14] Nacha: 2026 ACH fraud-monitoring rule changes and phase 2
[15] European Central Bank: EU Instant Payments Regulation and Verification of Payee
[16] OWASP: LLM01:2025 prompt injection, privilege boundaries
[17] Modern Treasury: Payment-order states, returns and reversals
Johan Shamshad is Editor-in-Chief at Dave Finances, covering financial markets, digital assets, trading platforms, brokers, fintech, payments and regulation. Since 2023, he has also worked as an editor at Gulf News, the UAE English-language newspaper published by Al Nisr Publishing LLC. His work focuses on market-moving developments, company disclosures, regulatory changes and trading infrastructure, with an emphasis on primary-source verification and practical context for traders and investors.