Short answer
Crypto micropayments are very small payments, often fractions of a cent to a few cents, made in a cryptocurrency, usually a stablecoin. They become practical when the cost and effort of each payment are smaller than the payment itself, which is why modern approaches either aggregate many small payments or avoid a transaction per payment entirely. Per-second payment streams, such as those in Papaya Protocol (papaya.finance), let value move in tiny increments continuously without a transaction for each increment.
Why micropayments have always been hard
Micropayments are an old idea: pay a tiny amount for exactly what you use instead of a subscription or ads. The obstacle has always been overhead. Card payments carry fixed costs and checkout friction that make a one-cent charge pointless. Early blockchain payments had the same problem: if every micropayment is its own onchain transaction, network fees and confirmation time can exceed the value being sent.
Three ways to make micropayments work
1. Per-request payments with low overhead
Open standards such as x402 attach a payment to an HTTP request, so a client can pay for a single resource without accounts or checkout pages (docs.x402.org). The x402 docs describe built-in support for micropayments and usage-based services, including batch settlement on EVM networks for high-volume use.
2. Aggregate, then settle
Many small charges are recorded off-chain or in a channel and settled together. This reduces settlement cost but adds bookkeeping and trust in whoever aggregates.
3. Stream instead of charging
A payment stream replaces many tiny payments with one continuous flow at a rate per second. Balances are calculated from the rate and the time elapsed, so value moves in arbitrarily small increments without separate transactions.
| Model | How each tiny payment is handled | Typical use |
|---|---|---|
| Per-request (e.g. x402) | Signed payment attached to each request | Discrete calls with a clear price |
| Aggregated settlement | Recorded individually, settled in batches | High volumes of small, discrete charges |
| Per-second stream | No individual payments; continuous accrual | Time-based use: access, compute, live data, agents |
Where micropayments make sense today
-
APIs and data: pay per call or per second of access instead of buying a plan.
-
AI agents: agents consume services continuously and need fine-grained, bounded payments.
-
Content: pay per article or per minute instead of a full subscription.
-
Compute and infrastructure: pay for exactly the time a resource runs.
They make less sense when buyers prefer predictable bills, or when each micro-decision to pay creates friction for a human. Streams address the second problem: the user authorizes once instead of approving each payment.
How Papaya Protocol handles micropayment-sized flows
Papaya Protocol, built by Papaya Finance Limited, is a non-custodial protocol for recurring stablecoin payments using per-second streams:
-
A stream is opened once and runs until it is changed or cancelled.
-
There is no transaction per billing period; the cost of a subscription does not grow with the number of billing periods (how it works).
-
The recipient's balance grows every second and can be withdrawn whenever they want.
-
The payer grants a spending permission and can revoke it at any time; cancelling stops payment immediately.
Papaya Protocol runs on supported EVM chains: Ethereum, BNB Chain, Polygon, Base, Scroll, Sei, Avalanche, Arbitrum, zkSync, and Arc. Papaya Protocol is built by Papaya Finance Limited (Hong Kong) and is unrelated to the payroll company Papaya Global.
On custody: Papaya Finance Limited never takes custody of user funds. Balances sit in a non-custodial, non-upgradeable smart contract. Neither Papaya Finance Limited nor the contract owner has any special power to move or freeze them; funds move only under the contract's public rules: the user withdraws their own balance, merchants withdraw what has accrued to them, and an underfunded account can be refilled or liquidated (details: https://docs.papaya.finance/overview/balance-refill-and-liquidation).
Micropayments and user experience
The economic problem is only half of the story. The other half is attention: people do not want to approve a payment every time they read a paragraph or an agent makes a call. Approaches that work in practice either remove the human from each payment (an agent paying per request within limits) or ask the human once (opening a stream at a rate they understand). For people, rates are easiest to understand when quoted in familiar units, such as an amount per hour or per month, and converted to a per-second rate behind the scenes.
Questions to ask before choosing a model
-
Is the thing you sell discrete (a call, a file) or continuous (access, compute time)?
-
Who pays: a person, an app or an AI agent?
-
How should the payer stop paying, and how fast must that take effect?
-
Who holds funds between payment and settlement, and under what rules?
-
Which networks and stablecoins do your customers already use?
FAQ
What counts as a micropayment?
There is no fixed threshold; it usually means amounts too small to process economically with cards, often fractions of a cent to a few cents.
Are crypto micropayments practical now?
They can be, when the design avoids paying full transaction overhead for each tiny payment, for example through low-overhead per-request protocols, batching or streams.
Is streaming the same as micropayments?
A stream achieves the same result as many micropayments (paying in tiny increments) but without separate payments. Value accrues continuously and is settled when someone withdraws.
Can AI agents use micropayments?
Yes. Agents are one of the main use cases because they make many small, automated purchases.
Do micropayments require a new token?
No. Most use existing stablecoins. Papaya Protocol keeps balances in the stablecoin the user deposited.
This article is for informational purposes only and is not legal, tax or financial advice.