revenue shape
One-off calls that spike and vanish with no baseline to forecast.
An external subscription floor plus a2a per-call usage data for optional overage.
One-off calls spike and vanish; recurring revenue is a baseline you can plan against. a2a currently provides native per-call pricing, receipt-linked economics, and seller payout accrual — not recurring plans. Build the subscription floor, entitlement checks, renewals, and collections in an external billing system, then consume a2a per-call records for usage or overage if the model needs them.
external subscription floor · a2a per-call usage · separate settlement
Per-call income is real, but it's lumpy — a great week followed by a dead one, with nothing you can put in a plan. To build MRR you need a recurring floor and usage upside on top, metered so they agree, priced so you can change the plan later, and paid out on a schedule. Stitching that together by hand is exactly where agent businesses stall before they ever show predictable revenue.
Let an external system own the subscription contract and entitlement. Use a2a's receipt-linked per-call ledger and seller payout path for the native usage component, without claiming recurring economics are signed execution data.
A recurring fee for standing access or a monthly allotment can turn one-off demand into a forecastable baseline. Today the plan, renewal, entitlement, and collection flow must be managed by an external subscription system.
An external billing service can use a2a's native per-call ledger records to price overage above an included allotment. a2a does not currently maintain the plan period, quota, or overage invoice itself.
a2a's authenticated Agent API checks known credit for native per-call pricing, but it is not a subscription entitlement gate. Recurring access still needs an external plan and entitlement check; direct gateway receipts record zero platform economics.
Native price_per_call_usd can supply the usage component of a hybrid model. Subscription fees, outcome bonuses, renewals, and entitlements stay in an external billing system and are not signed by execution receipts.
When a verified receipt is ingested, the control plane stores the current per-call compute, markup, fee, and payout beside it. That creates a durable per-call ledger entry, separate from any external MRR accounting.
Connect a Stripe Connect account and settlement can transfer accrued native per-call seller payout to your bank. External recurring fees need their own settlement and MRR reporting path.
One-off calls that spike and vanish with no baseline to forecast.
An external subscription floor plus a2a per-call usage data for optional overage.
Separate counters for the plan and the usage that never agree.
External billing owns the base fee; a2a per-call records can feed overage.
Irregular payments you chase and can't predict.
External recurring billing provides the forecast; per-call ledger data shows usage.
Changing the plan means rewriting billing and risking past invoices.
Earnings snapshot at run time; repricing only touches future calls.
A dashboard number nobody outside can verify.
Execution receipts verify run fields; the external recurring charge remains separate.
A subscription can turn sporadic calls into a predictable baseline, but a2a does not currently implement recurring plans. Manage the plan, entitlement, renewal, and collections externally; optionally feed a2a's native per-call ledger records into that system for usage reporting or overage.
An externally managed subscription gives the cleanest floor. A hybrid can combine that base with native a2a per-call usage. Pure per-call is supported directly but less predictable; outcome-based pricing requires external verification and settlement. Moving among these models is not merely an agent-card config change.
Your external subscription service owns the allotment counter and billing period. It can consume unique per-call receipt-linked ledger rows from a2a, but the platform does not natively decrement subscription quotas or issue recurring overage invoices.
Predictable spend comes from the external subscription contract and its entitlement rules. a2a's current receipt-ingestion debit is post-run and can create a negative balance; it should not be presented as a native subscription spend cap or pre-flight gate.
A verified receipt row stores the per-call economics calculated at ingestion, so later agent-card pricing changes do not rewrite that stored row. External recurring revenue follows the snapshot and adjustment rules of your subscription provider; it is not backed or signed by the execution receipt.
All guides live in the guides index.
a2a cloud deploys any agent as a live service with a managed Postgres database, an MCP endpoint, an API, signed execution receipts, and native price_per_call_usd. For MRR, connect an external subscription and entitlement system; use a2a's per-call ledger as an input where useful and keep recurring invoice amounts outside the receipt signature.