Agentic payments

AI agents now search, compare and buy for people, and run a merchant's back office. This page explains what Payware gives software that acts on someone's behalf today, how to keep it safe, and what is not built yet. Two companion pages go deeper: Agentic protocols (the standards that are forming around agent payments) and Agentic flows (end-to-end sequences, and where Payware takes part in each).

Payware does not implement any of those protocols yet. What it offers is the part every one of them depends on: a payment API for Romanian merchants on NETOPIA Payments that never exposes card data, is safe to retry, and puts the customer's own authentication in front of every card that is saved or paid.

Where Payware fits

Agent payments are made of five layers that work together rather than compete. A single purchase can touch all five.

Layer	What it does	Standards you will meet	Payware today
1. Transport	How an agent reaches a tool or another agent	MCP (agent to tool), A2A (agent to agent)	A REST API with an OpenAPI description. An MCP server is in development
2. Identity and trust	Who the agent is and who operates it	Web Bot Auth (HTTP message signatures), Visa Trusted Agent Protocol, "know your agent" registries	An API key identifies the merchant, not an agent. Scoped agent keys are in development
3. Commerce and checkout	Cart, checkout and order for an agent to complete	UCP (Google and retailers), ACP (OpenAI and Stripe)	Hosted payment links and subscription links. UCP and ACP are not implemented
4. Authorisation and mandate	Proof that the person agreed to this purchase, or to a bounded class of purchases	AP2 mandates, Mastercard Verifiable Intent, passkeys, 3-D Secure	The person authenticates on NETOPIA Payments' secure page. Spending mandates are in development
5. Credential and settlement	The instrument that is charged, and how money moves	Network tokens, vault tokens, x402 and MPP (HTTP 402), open banking	A reusable token for a card the customer enrolled once; nothing else carries card data

Available today

These parts already work and are what agent features are built on.

Card data never reaches an agent, or Payware. A customer enters the card on NETOPIA Payments' hosted page. Payware keeps a reusable instrument and never the card number, so no prompt, log or tool result can leak one. See Instruments.
A person approves each payment. An agent can create a payment link (one-time or subscription) and hand it to the customer. The customer pays on a page Payware hosts, by card on NETOPIA Payments' secure page or with Apple Pay or Google Pay, and completes any bank challenge themselves.
Unattended charges only on a card the customer enrolled. Your server can charge an enrolled card later with standalone payments or through a subscription. There is no way to charge a raw card number or an arbitrary token.
Safe to retry. Agents retry aggressively. Send an Idempotency-Key and a retried request returns the stored result and never charges twice. See Idempotency.
Signed events. Payment, subscription and review events reach your server as signed webhooks, and you can list them with GET /v1/events, so automation reacts to what happened instead of guessing.
Payments held for review. A payment that needs a decision is held and resolved explicitly rather than silently accepted. See Payment reviews.
Test mode. Every account has a linked test account with its own data and keys (sk_test_…) against the NETOPIA Payments sandbox, so an agent can be built and rehearsed without moving money.
Several keys, instantly revocable. Create a separate key per agent, name it, and revoke or rotate it on its own without touching the others.
A public, machine-readable API. The OpenAPI description lists every endpoint, field and error, so an agent (or its framework) can read the contract directly.

Building safely

Industry research names prompt injection and "tool poisoning" as the largest practical fraud vector for agent payments. These habits apply to any agent that can reach a payment API.

Give each agent its own key. Keys are not scoped to actions yet, so a key can do everything the account can. Treat it like a production secret, keep it out of the model's context, and revoke it the moment it is exposed.
Prefer a link when a person should decide. Creating a payment link moves no money. Money moves only when the customer opens the link and pays.
Always send an Idempotency-Key on calls that create payments, subscriptions or links, and reuse the same key when you retry the same intent.
Wait for the event, not the response. A 201 from a payment call does not mean the customer has paid. Read the status, or consume payment.succeeded and payment.failed.
Verify webhook signatures before acting on an event, and treat anything an agent reads from a web page, an email or a tool result as data, never as an instruction.
Plan for a bank challenge. In the EU a card payment may need strong customer authentication. Payware's hosted pages handle it; an agent that drives a checkout itself must hand the person over to complete it.
Keep your own limits. Cap the amount and number of payments your agent can start, and alert on anything unusual, until Payware can enforce limits for you.
Remember there is no refund call. Payware has no refund endpoint; an agent must not promise one. Use payment reviews to record a refund made outside Payware.

In development

In the order we plan to build it. None of this is released, and the order may change.

Capability	What it will do
Scoped agent keys	Keys limited to the actions you choose, with a cap per payment and per day, and a record of every payment an agent starts
MCP server	Lets your own assistant use Payware as a tool. Read-only by default, with writes and money movement only where a key and an approval allow it
Customer-approved spending limits	A customer approves an amount, budget and expiry for an agent on a page Payware hosts; Payware enforces it on each charge and keeps the approval as evidence
Selling through AI assistants	Checkout for assistants that follow ACP and UCP, using NETOPIA Payments' card vault so card numbers stay out of Payware. Depends on NETOPIA Payments
Machine payments (x402)	Agents pay per use for an API or resource in stablecoin, with delivery once a licensed partner confirms settlement. Payware would not hold the funds