> Source: [/docs/resources/guides/subscriptions-on-tempo](https://tempo.xyz/developers/docs/resources/guides/subscriptions-on-tempo.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) / [Payment workflows](https://tempo.xyz/developers/docs/resources/guides#payment-workflows) / Subscription billing with access keys # Subscription billing with access keys Use a scoped access key with a periodic spending limit to authorize recurring stablecoin charges. Your application schedules each charge, verifies payment, and manages the subscription. The key constrains spending; it is not a billing scheduler. Access keys work on mainnet and testnet with single-key accounts. Until [T14](https://tempo.xyz/developers/docs/protocol/upgrades/t14), access keys for configurable accounts run only on the Tempo Accounts devnet. Follow the [access-key guide](https://tempo.xyz/developers/docs/accounts/access-keys) when choosing the account and network for your integration. ## Define the subscription and authorization Record the customer account, asset contract, charge amount, billing schedule, service entitlement, cancellation terms, and key expiry. Keep those application terms distinct from the onchain bounds. An [access key](https://tempo.xyz/developers/docs/accounts/access-keys) signs from the customer's account and spends its balance. The key holds no funds. The account's authorized signers approve the key, then the service can use it within its permitted spending, scopes, and expiry without a new signer approval for every payment. For a billing service, set all three bounds: * **Spending limit:** the maximum amount of the allowed token in a fixed period. * **Scopes:** the contracts, functions, and supported recipient restrictions the charge needs. * **Expiry:** when the delegated key stops working. Omitting a bound removes that check. A key without scopes can call any contract; a spending limit doesn't restrict the payment destination. ## Align fixed periods with the billing model [Periodic spending limits](https://tempo.xyz/developers/docs/accounts/access-keys/spending-limits) use a duration in seconds. The first period starts when the key is authorized, not at midnight or a calendar boundary. At the period boundary, the limit resets to its full amount; unused amounts don't carry over. For example, an application can request authorization for up to 50 units of its chosen stablecoin every seven days until a specified expiry. The service schedules charges according to its terms and checks the remaining allowance before each charge. Fixed durations are different from calendar months. If the product bills on a monthly anniversary, define how that schedule maps to the authorized fixed-duration budget rather than calling a fixed number of days “one month.” A spending limit also covers fees paid by the account, approval increases, and other counted TIP-20 outflows. A charge equal to the whole limit can fail if the same limited balance must cover its network fee. Use a separately funded [fee payer](https://tempo.xyz/developers/docs/guide/payments/sponsor-user-fees) where appropriate, or make the fee allowance explicit. Read [what counts against a spending limit](https://tempo.xyz/developers/docs/accounts/access-keys/spending-limits#what-counts). A `transferFrom` that uses an allowance the account already granted doesn't count against the key's spending limit, so a periodic key limit doesn't cap every debit from the account. Review existing token allowances. ## Scope the key to the billing operation Scope the token contract and function selectors the charge requires. A scope for `transfer(address,uint256)` doesn't allow `transferWithMemo(address,uint256,bytes32)`; a payment-reference flow needs the appropriate additional scope. Where supported, restrict the recipient to the billing account. The [scope guide](https://tempo.xyz/developers/docs/accounts/access-keys/scopes) describes the functions that support recipient restrictions. Scopes check direct calls signed by the key. A permitted contract can make its own downstream calls, so review that contract and any existing token approvals before allowing it. Give each service its own key so it can be revoked independently. Protect the service's private key and preserve its authorization metadata alongside the subscription record. ## Schedule and reconcile recurring charges :::steps ### Create one record per billing period Use a stable subscription and period identifier. Save the asset, amount, due time, customer account, authorization, and entitlement to extend. Enforce uniqueness before submitting a charge. ### Check authorization and funding Confirm the key is active, unexpired, correctly scoped, and within its remaining limit. Check the customer's payment balance and the selected fee payer's balance. A renewed spending limit doesn't add funds. ### Submit and preserve the attempt Follow [sending payments](https://tempo.xyz/developers/docs/guide/payments/send-a-payment). Save the transaction identifier against the period record. If a request times out, inspect that attempt before submitting another charge. ### Confirm delivery before extending service Follow [receiving payments](https://tempo.xyz/developers/docs/guide/payments/accept-a-payment) to verify the successful transaction and expected delivered transfer. Match the network, token, recipient, amount, and payment reference. A receive-policy hold is not a delivered charge. ### Update payment and entitlement records once Store the verified transfer with its network, transaction hash, and log index. Mark the period paid and extend the service entitlement atomically. Repeated jobs or callbacks should return the existing outcome. ::: Use states such as **due**, **submitted**, **paid**, and **needs attention** in the application. Define which failures can be retried, how the customer is notified, and what happens to service access during a funding or authorization problem. ## Handle cancellation, expiry, and changes Stop new billing when the subscription is canceled. Keep customer cancellation, service entitlement, and onchain signing permissions as explicit records. If cancellation includes key revocation, submit it and verify the result; changing an application status doesn't revoke a key. [Revoking a key](https://tempo.xyz/developers/docs/accounts/access-keys/revocation) ends its authority permanently. Prior payments remain final, and existing token approvals remain until changed separately. An expiry also ends future signing authority; a new billing period doesn't extend it. If a customer changes a spending limit, read back the resulting authorization. Updating a limit resets the remaining amount to the new value; it doesn't add the difference to what was left. The period and its current end remain unchanged. Follow the [limit update rules](https://tempo.xyz/developers/docs/accounts/access-keys/spending-limits#change-a-spending-limit) when implementing plan changes. Keep personal details and subscription terms offchain. Use an opaque [payment reference](https://tempo.xyz/developers/docs/guide/payments/transfer-memos) to connect the transfer to the billing record. ## Subscription billing questions ### Does a periodic limit charge the customer automatically? No. It bounds what the service can spend during each period. Your application schedules and submits charges and checks that the requested payment was delivered. ### Does the period reset refill the customer's balance? No. It replenishes the key's spending allowance. The account still needs payment funds, fee funding, valid permissions, and an unexpired key. ### Should usage-based APIs use subscriptions? Use the model that matches the service. [MPP payment sessions](https://tempo.xyz/developers/docs/guide/machine-payments/pay-as-you-go) account for repeated usage with cumulative vouchers against a funded channel. Periodic access-key limits can bound an agent's spending without turning the session into a fixed subscription. See [metered billing](https://tempo.xyz/developers/docs/resources/guides/microtransactions).