Web Bot Auth and Visa TAP: Where Agent Names Fit
Your agent reaches a supplier's payment portal with an approved invoice ready to pay. The supplier needs to recognize the caller, your payment controls need to stay attached, and customers need a way to find the official service behind that traffic.
Web Bot Auth and Visa's Trusted Agent Protocol (TAP) support signed request recognition. A Headless Domains name connects your agent's public identity to its service information; the receiving application verifies the association with its signing identity and applies the permissions for the requested action.
Visa TAP now has a live invoice-payment pilot
Visa, BILL and Billtrust announced a live B2B payment pilot on October 20, 2026. An authorized BILL Payment Agent completes eligible invoice payments that the buyer has already approved. Participating BILL buyers and Billtrust suppliers are processing transactions through the pilot.
- The buyer approves the payment instructions.
- The BILL Payment Agent, registered using Visa TAP and Agentic Directory, uses tokenized payment credentials and buyer-defined controls.
- Billtrust recognizes and authenticates the agent, applies the supplier's acceptance policy and grants access to the invoice-specific payment path.
- The agent completes the payment, with visibility into authorization and completion.
The pilot avoids sharing supplier-portal logins. The agent executes approved payments; it does not decide which invoices the buyer should pay. Access remains limited to the participating arrangements.
Connect the recognized caller to an identified buyer and the approved invoice, then keep that connection visible through completion. Your customer can account for the payment without piecing the story together from a chat.
What the request signature establishes
RFC 9421, HTTP Message Signatures, defines how a sender signs selected parts of an HTTP message. The verifier checks the signature against an accepted key and the signature profile's rules, including freshness and replay handling.
Only the covered components receive that protection. A valid signature establishes a cryptographic fact about the message; your application still decides which service the signer represents and which actions to allow.
Web Bot Auth connects requests to signing keys
The Web Bot Auth working-group draft uses Signature-Agent for signing-key discovery. Its persistent identifier is the resolved HTTPS URL associated with the keys that verify the request, so the identifier can remain stable through key rotation.
The protocol remains an Internet-Draft. Its Datatracker page tracks the active version. Successful verification supplies request identity evidence; the receiving service separately evaluates the operator relationship, behavior and access policy.
Visa TAP connects recognition to its commerce program
Visa's current TAP developer documentation describes agent recognition for commerce traffic. TAP builds on HTTP Message Signatures and includes consumer-recognition and payment objects alongside agent-recognition signatures.
Your agent provider needs the applicable Visa participation and registration arrangements. A Headless Domains registration supplies public naming and records; Visa approval and merchant acceptance come through their respective programs and policies.
MPP can carry identity through paid retries
The mppx identity release adds configured Web Bot Auth and TAP support to initial requests and automatic paid retries. A server can verify the request attestation before handling the payment challenge or credential.
The MPP identity guide separates the request signer from the identity authorizing payment. The signer may represent an agent provider, while the payment credential identifies the payment-authorizing key. Its Web Bot Auth verifier receives keys through the application's trust policy rather than blindly fetching an untrusted caller-supplied directory.
If one provider signs for several agents, the provider signature alone may not distinguish your agent from its other customers. Keep authenticated agent context in the integration when individual attribution matters.
Connect a public agent name to the working service
Imagine a procurement assistant called procurement.agent. Customers recognize the service by that name. Its documentation, signing provider and payment integration can live at different addresses, with the public record giving callers a route to the current information.
The Headless Domains and SkyInclude infrastructure supports those lookups through API and command-line workflows. Your agent's public name does not depend on conventional browser resolution. The signature implementation uses its supported HTTPS identity and key-discovery routes.
Build the association in the application handling the traffic:
- Publish the operator, official service documentation and supported interface references through the name's records.
- Establish an authenticated association between the public name and the accepted signing identity, using your provider's enrollment or another mechanism the verifier trusts.
- Validate each request with the correct signature profile and trusted key source. Attribute it to an individual named agent only when the evidence supports that association.
- Apply action permissions and payment approval in the systems responsible for them.
You configure this association in the relying application. Headless Domains provides public naming and read-only discovery, as described in its API contract; it does not automatically enroll the service in TAP, bind a public name to a signing key or execute the discovered action. The agent identity graph guide covers the wider relationship map.
Keep buyer approval attached to the purchase
For AP2-based purchases, the AP2 specification defines checkout and payment mandates with verification duties; its autonomous flow binds an open mandate to an agent key. Your implementation connects the recognized requester, approved purchase and payment evidence according to the protocols it supports.
Use the x402, AP2 and MPP comparison to choose a payment flow. Here, keep the question focused: which named service sent this request, what supports that identity, and what did the buyer approve?
Give customers a name they can return to
A customer can remember the procurement service while its hosting, keys and payment connections evolve. Publish the official routes, maintain the name's records and keep the verified signing association current in your application.
Share the HeadlessDomains.com setup instructions with your assistant. Choose a name for the agent you operate and connect it to the service information your customers and compatible clients need.
Connect your name to the service with What to Do After Registering a Headless Domain: 7 Next Steps.