--- title: "Subscriptions on Tempo: Onchain Billing Made Easy" description: "Enable subscription billing onchain with Tempo's access keys, supporting periodic spending limits for human subscribers and AI agents alike." path: "/blog/subscriptions-on-tempo/" date: "2026-04-27T12:00:00Z" label: "Product" image: "/cards/blog-subscriptions-on-tempo.webp" --- **_Tempo's [access keys](https://docs.tempo.xyz/docs/accounts/access-keys) now support periodic spending limits, making subscription billing possible onchain without re-prompting users or holding their keys. The same mechanism works for human subscribers and AI agents. If you want to build recurring or scoped billing flows using stablecoins, [contact Tempo](/contact/)._** Many business models center around recurring billing: a customer pays a set amount every week, month or year for a product or service. This model works fine when the customer wants to pay using a credit card. It works less well for customers without a card or AI agents, who increasingly rely on stablecoins. For usage-based flows, [MPP Sessions](/blog/mpp-sessions) handles high-frequency payments without charging onchain for every request. While stablecoins handle one-time global payments cleanly, recurring billing has been harder. One option is to require fresh user approval at each charge. The other is to get approval from the user for significantly more funds than immediately needed, e.g., an approval for a year's worth of payments. This results in very poor UX and heightens the risk for consumers. Tempo [access keys](https://docs.tempo.xyz/docs/accounts/access-keys) let users delegate signing authority to a service with defined constraints: spend up to a fixed total, on specific tokens, until a given expiry. Access keys now also support periodic spending limits, which enables subscriptions. ## How Tempo solves the problem Access keys are a native primitive on Tempo that enables a wide range of payments use cases. This is how access keys work on Tempo: - A user authorizes an access key, specifying a maximum amount and an expiry. - They can hand this access key to a service without handing over control to their entire account. - A service can use the access key to "pull" funds from the user's account within that limit and until it expires. - Access keys can also be scoped to specific contracts and function selectors, so a key for one service can't be used elsewhere. The user can always revoke the authorization at any time. ![Subscriptions on Tempo](/blog/subscriptions-on-tempo-diagram.webp) With periodic spending limits, that authorization now includes a per-period cap that resets automatically: - A service can be granted a right to spend, e.g., "$50 per week for the next 50 weeks" rather than a lump-sum total.[^1] - The protocol checks each charge against the current week's remaining allowance. A charge still needs sufficient funds, valid authorization, and any applicable transfer permissions. - When the week ends, the window resets. The user sets terms once, and the service charges on schedule without re-prompting. ## What this enables Access keys make recurring payments with stablecoins practical in a way they weren't before, without repeated approvals or overly permissive authorizations. A SaaS company can use the same onchain billing flow for subscribers who can fund a supported stablecoin account: one access key authorization followed by periodic charges. Funding availability, customer eligibility, and any conversion to local currency still depend on the services used in each market. Similarly, an AI agent that consumes a paid inference API can be granted a key scoped to that API's contract with a $25 weekly limit, complementing the real-time billing enabled by [MPP Sessions](/blog/mpp-sessions). The agent calls the service throughout the period using the access key to authorize payment. Each charge is validated against the remaining allowance, and the limit resets automatically. Combine the spending limit with the permitted contracts and calls; a budget alone does not restrict every possible use of the key. Finally, access keys also enable simple subscription services that charge a fixed periodic amount. For example, a user subscribes to a newsletter or a streaming service by authorizing an access key with a matching limit. ## Operate recurring billing reliably The access key authorizes spending; your application schedules and reconciles the charges. For each subscription, save the customer account, asset contract, billing period, amount, and authorization expiry. Give every billing period a unique record so a repeated job cannot create a second charge for the same period. For example, a weekly subscription can move through **due**, **submitted**, **confirmed**, or **needs attention**. Save the transaction identifier when submitting. If a request times out, inspect that payment before sending another. Confirm the expected transfer before marking the invoice paid or extending access to the service. See [receiving payments](https://docs.tempo.xyz/docs/guide/payments/accept-a-payment) for the delivery checks. When funds are insufficient, notify the customer and apply the service's stated retry and access policy. A replenished periodic limit does not add funds or extend an expired key. Stop new billing when a subscription is canceled, and confirm any onchain key revocation. Keep customer cancellation, service entitlement, and signing permissions as explicit application records. Use an opaque [payment reference](/learn/transfer-memos/) to connect a charge with its billing record. Keep customer details and subscription terms offchain. If the service pays the customer's network fee, configure [fee sponsorship](/learn/fee-sponsorship/) separately from the subscription amount. ## Getting started If you're building recurring billing, agentic payments or stablecoin cards on Tempo, start with the [access keys documentation](https://docs.tempo.xyz/docs/accounts/access-keys) to understand key scoping and periodic limits, or explore [MPP Sessions](/blog/mpp-sessions) for usage-based billing patterns. Recurring billing is one of several new enterprise features live on Tempo today. For the full picture, see [new features on Tempo for enterprise payments](/blog/new-features-for-enterprise-payments). To discuss your use case with the product team, get in touch at [tempo.xyz/contact](https://tempo.xyz/contact/). [^1]: Recurring limits currently only support fixed time periods (e.g., 1 day, 1 week). Calendar support (e.g., 1 month) will be available after a future upgrade.