> Source: [/docs/resources/guides/microtransactions](https://tempo.xyz/developers/docs/resources/guides/microtransactions.md) > Section: [Get Started](https://tempo.xyz/developers/get-started.md). Choose a starting point, send a test payment, get testnet funds, connect a coding agent, find the SDKs and CLI, and use the resource guides to plan payment workflows, liquidity, provider selection, and partner integrations. > [Documentation index](https://tempo.xyz/developers/llms.txt) · [Docs skill](https://tempo.xyz/developers/SKILL.md) > Tempo MCP: Use `search`, `find_pages`, `read_page`, and `code` at `https://mcp.tempo.xyz` for Tempo and related documentation. > If an indexed page is missing or reflects an older site, read this site’s [documentation index](https://tempo.xyz/developers/llms.txt) and Markdown pages directly. [Guides](https://tempo.xyz/developers/docs/resources/guides) / [Machine payment models](https://tempo.xyz/developers/docs/resources/guides#machine-payment-models) / Microtransactions and metered billing # Microtransactions and metered billing Microtransactions are small payments for individual resources or units of service, such as an API result, article, or minute of usage. On Tempo, collect them as direct charges, payment sessions, or aggregated recurring bills. Define the purchased unit and compare delivery and collection costs before setting the price. ## Choose how to collect small charges | Billing pattern | Use it for | Records to maintain | | --- | --- | --- | | Direct payment | A distinct purchase with a defined price and result. | Purchase, verified delivered transfer, and customer entitlement. | | Payment session | Repeated requests or streaming usage against a funded channel. | Billable units, cumulative vouchers, channel deposits, and settlements. | | Recurring payment | A fixed charge on an application billing schedule. | Subscription, billing period, authorization, charge, and service entitlement. | Tempo's [stablecoin fee system](https://tempo.xyz/developers/docs/resources/guides/stablecoin-fees) supports sub-cent network fees for standard transfers. Acquiring the asset, custody, currency conversion, service delivery, and customer support cost extra. Compare the complete costs of individual charges, sessions, and aggregated invoices before setting a price. ## Define the billable unit For an API, decide whether you charge for a request received, a successful result, compute consumed, or another measurable unit. For content, define the purchased entitlement: a specific article, a playback period, or repeat access to an existing purchase. Record the price, asset, network, quantity, and delivery rule before requesting payment. Version pricing so an interrupted request can be resolved against the terms the customer accepted. For agent purchases, [HTTP 402 and MPP](https://tempo.xyz/developers/docs/resources/guides/402-payment-required) let a service communicate payment requirements inside an HTTP request. The application decides which usage is billable. ## Collect a direct purchase Use [one-time MPP payments](https://tempo.xyz/developers/docs/guide/machine-payments/one-time-payments) for payment-gated APIs, or the [receiving guide](https://tempo.xyz/developers/docs/guide/payments/accept-a-payment) for a direct token transfer. Before fulfilling a direct payment, verify its network, token contract, recipient, amount, and successful delivered transfer. Save the transfer's network, transaction hash, and log index so it credits the purchase once. A matching memo only identifies which business record to check. When the customer requests the same purchased article or result again, return the existing entitlement according to your product terms. Don't charge a second time because a response was interrupted or a user refreshed a page. ## Meter usage through a payment session [Pay-as-you-go sessions](https://tempo.xyz/developers/docs/guide/machine-payments/pay-as-you-go) account for usage through signed cumulative vouchers against a funded channel. The service verifies the authorized amount before delivering additional usage and can settle vouchers onchain. For streaming content, follow the [streamed payments guide](https://tempo.xyz/developers/docs/guide/machine-payments/streamed-payments). Keep these states distinct: * **Usage delivered:** the units the application has actually supplied. * **Usage authorized:** the amount covered by the current valid voucher. * **Channel funding:** the tokens deposited into the channel. * **Funds settled:** the amount collected onchain. Request another voucher when more usage needs authorization. Add channel funds when the deposit is insufficient. Closing and settlement follow the channel's rules, including the handling of unused funds. A session can need several top-ups or settlements. ## Constrain delegated spending [Access keys](https://tempo.xyz/developers/docs/accounts/access-keys) let a device, backend, or agent sign within defined spending limits, scopes, and expiry. A [spending limit](https://tempo.xyz/developers/docs/accounts/access-keys/spending-limits) caps the TIP-20 spending counted by the keychain; it doesn't measure API usage or schedule invoices. Transfers that use an existing allowance and assets other than TIP-20 tokens fall outside that limit, so review existing approvals as well as the key's bounds. Set scopes for the contracts and functions the integration needs. Add recipient restrictions where the supported function allows them. Scopes check direct calls, so permit only contracts you trust. Fees the account pays consume its access-key limit; [fee sponsorship](https://tempo.xyz/developers/docs/guide/payments/sponsor-user-fees) moves that network expense to a separate fee payer. Access keys work on mainnet and testnet with single-key accounts. Configurable-account access keys remain on the Tempo Accounts devnet until [T14](https://tempo.xyz/developers/docs/protocol/upgrades/t14). ## Operate a metered billing service :::steps ### Record usage and delivery together Assign a stable identifier to each billable operation. Preserve the accepted price, measured units, delivered result, and associated payment or voucher. Define how failed and repeated requests affect the charge. ### Reconcile collection with consumption For direct payments, reconcile verified transfers with purchases. For sessions, reconcile usage and vouchers with channel funding and onchain settlements. Track unresolved differences explicitly. ### Exercise billing exceptions Test insufficient funds, exceeded limits, revoked keys, interrupted streams, duplicate requests, and failed delivery. Verify that a retry does not duplicate usage or payment, and that customers can recover an already purchased result. ::: ## Microtransaction questions ### How small can a payment be on Tempo? The usable minimum depends on token precision, network fees, funding costs, and the service being purchased. Sessions can aggregate small usage charges between onchain settlements; they don't make collection free. ### Do customers need a standalone wallet application? A stablecoin payment needs an account and a way to authorize spending. A wallet provider can embed that experience in your product. Define funding, key management, recovery, and purchase support as part of the integration. ### Can the same infrastructure support subscriptions? Yes. Access keys support periodic spending limits, while your application schedules and reconciles charges. A renewed spending limit doesn't add funds or extend a key's expiry. See [subscription billing](https://tempo.xyz/developers/docs/resources/guides/subscriptions-on-tempo).