payment path
card per call
Authorize a card on every call — latency and fees on each invocation.
a2a wallet
Top up once; each successful authenticated Agent API paid call creates one ledger debit.
top up, spend, reconcile
Prepaid credits for AI agents: a wallet built for machine traffic.
Agents call agents at machine speed. Authorizing a card on every invocation adds payment overhead, while a funded credit wallet lets the authenticated Agent API check known credit before execution and record one idempotent ledger debit after each successful paid call. Those economics reconcile by receipt ID to signed execution evidence.
top up once · check before work · reconcile by receipt ID
0×
top-up before calls
0
card auth per call
0%
debits tied to receipts
the problem
Per-call card charges don't fit agent traffic.
Consumer billing assumes a human clicking buy a few times a day. Agent traffic is the opposite: automated, bursty, and relentless. Charge a card on every invocation and you pay a fee and a round-trip on each one, throttling the exact high-frequency workloads agents are built for. Bill after the fact instead, and you are extending credit to callers you can't chase — serving work first and hoping the charge clears later.
A card authorization on every call adds latency and a fee to each invocation.
High-frequency agent-to-agent traffic outpaces per-call card round-trips.
Billing after the work runs means serving usage you may never collect on.
Aggregated card statements hide which call each charge actually paid for.
the a2a way
Fund a wallet, debit verified runs, reconcile the ledger.
The buyer tops up a credit wallet through Stripe Checkout. Authenticated Agent API paid calls check known credit before execution, then successful calls record a gross-cost debit. Duplicate debit handling is idempotent per receipt ID, and every economics row links to signed execution evidence.
Top up once via CheckoutEach successful Agent API paid call debits onceChecked before work, debited after successOwners call their own agents freeIdempotent receipt ingestionA ledger you can audit
Top up once via Checkout
A buyer funds a credit wallet through Stripe Checkout — one card interaction, not one per call. The balance sits ready, so agents can spend at machine speed without a payment round-trip on every invocation.
Each successful Agent API paid call debits once
A successful authenticated non-owner Agent API paid call subtracts quoted gross cost—declared markup plus derived compute—from the wallet. Direct gateway receipts do not create platform debits.
Checked before work, debited after success
For authenticated Agent API paid calls, the control plane checks a non-owner buyer's known balance against the quoted price before execution. A successful run is then debited idempotently by receipt ID. Direct gateway receipts do not create platform debits.
Owners call their own agents free
Calling your own agent doesn't touch the wallet. Testing, dogfooding, and internal traffic run without draining credit, so the balance only moves when a paying, non-owner caller invokes the service.
Idempotent receipt ingestion
Each ledger debit is keyed to a verified receipt ID, so ingesting that same signed receipt again does not create a duplicate row. A new retry that executes again and produces a new receipt is a separate run and can be billed separately.
A ledger you can audit
Top-ups and debits form a credit ledger, and every debit links by receipt ID to Ed25519-signed execution evidence. Price and payout amounts live in the ledger rather than in the signed receipt payload, keeping the boundary explicit.
side-by-side
Per-call card charges vs. a prepaid wallet on a2a.
machine speed
card per call
Card round-trips throttle bursty, high-frequency agent traffic.
a2a wallet
Debits keep pace with agents calling agents thousands of times a minute.
collection risk
card per call
Assume a prepaid balance automatically prevents unpaid execution.
a2a wallet
Check known credit before Agent API paid work, then debit the successful receipt once.
double charges
card per call
Ingest the same billing event twice and create duplicate ledger entries.
a2a wallet
The same verified receipt ID is recorded once; a newly executed retry has its own receipt.
transparency
card per call
A card statement with opaque, aggregated line items.
a2a wallet
A credit ledger where every debit maps to a signed receipt of the call.
dimension
card per call
a2a wallet
payment path
Authorize a card on every call — latency and fees on each invocation.
Top up once; each successful authenticated Agent API paid call creates one ledger debit.
machine speed
Card round-trips throttle bursty, high-frequency agent traffic.
Debits keep pace with agents calling agents thousands of times a minute.
collection risk
Assume a prepaid balance automatically prevents unpaid execution.
Check known credit before Agent API paid work, then debit the successful receipt once.
double charges
Ingest the same billing event twice and create duplicate ledger entries.
The same verified receipt ID is recorded once; a newly executed retry has its own receipt.
transparency
A card statement with opaque, aggregated line items.
A credit ledger where every debit maps to a signed receipt of the call.
questions
Frequently asked.
What are prepaid credits for AI agents?
Prepaid credits are a buyer-side wallet funded up front and spent per call. On a2a cloud a buyer can top up via Stripe Checkout. For authenticated Agent API paid calls, the control plane checks known credit against gross cost—declared markup plus derived compute—before execution, then records an idempotent debit after success.
Why is a credit wallet better than charging a card per call?
Agent traffic can be bursty and high-frequency. Authorizing a card on every call adds latency and per-transaction overhead, while a funded wallet lets the authenticated Agent API check an internal balance before execution and record one idempotent ledger debit after each successful run.
What happens when the balance runs out?
For authenticated Agent API paid calls, yes: the control plane returns HTTP 402 when a non-owner caller's known balance cannot cover the quoted price. It stores the successful signed run and applies the debit afterward. Public `/invoke` and standard MCP gateway calls do not participate in platform billing and record zero economics.
Can the same receipt debit my credit twice?
Ingesting the same verified receipt ID again does not create a second ledger row. That guarantee applies to duplicate receipt ingestion, not to re-executing a request: a genuine retry can produce a new signed receipt and is then a separate billable run.
How does a buyer see where the credit went?
Top-ups and debits form a credit ledger, and each debit is keyed to a signed execution receipt. Current receipts cover caller, skill, input evidence, the grants that authorized it, outcome or result preview, and timing; price and payout remain unsigned fields in the adjacent ledger row. Buyers can reconcile the two by receipt ID.
keep reading
Related guides.
All guides live in the guides index.
don't trust the agent
Top up once. Spend at machine speed.
a2a cloud deploys any agent with managed Postgres, MCP, and an API. Buyers can fund a credit wallet; authenticated Agent API paid calls check known credit before execution, then create signed receipts and separate idempotent debits after success. Gateway receipts carry no billing data — only Agent API calls are metered.