05 / BILLING AND USAGE
React Native AI subscriptions: entitlements vs credits
Keep subscription entitlements, saved-result access and AI usage in separate records. Your billing integration verifies purchases; your server decides which features they unlock and when a completed AI operation consumes a credit. Restoring a purchase must not blindly refill the usage balance.
Use three records with different jobs
| Record | Answers | Example fields |
|---|---|---|
| Entitlement | May this account use a paid feature now? | App user ID, product, state, expiry, verified event reference. |
| Report access | May this account read this delivered result? | Report ID, owner, version, access policy and any revocation. |
| Usage ledger | What allowance remains, and why? | Grant period, operation ID, reservation, settled debit or released reservation. |
RevenueCat entitlements can represent access to premium features. That does not automatically define the cost of a model request, your report ownership policy or an atomic app-specific credit ledger. Avoid treating a cached client flag as authority for a paid server request.
Define the customer-visible states first
| Situation | New AI request | Existing purchased report |
|---|---|---|
| Active entitlement, credits available | Allowed after server reservation. | Readable under its report-access policy. |
| Active entitlement, zero credits | Explain the limit and next reset or purchase option. | Still readable if sold as retained access. |
| Subscription expires | Apply the agreed expiry or grace policy. | Do not revoke a separately purchased report unless its agreed policy requires it. |
| Purchase restored | Refresh verified access; reconcile existing grants. | Reconnect only the reports associated with the correct app account. |
| Refund or revocation | Reconcile the verified event and access policy. | Apply the disclosed report policy; do not guess from the device UI. |
“Cancel subscription” and “lose access now” are not interchangeable. Use the verified store state, expiry and your grace-period policy. Document these terms before purchase rather than surprising the customer at the point of use.
A request and a webhook need different idempotency keys
- Associate the verified purchase with your app account using a documented identity policy.
- Deduplicate store or billing events by provider event ID. Handle delayed and out-of-order events by reconciling authoritative state.
- Create a credit grant with a unique account-and-period key. A repeated webhook must not create another grant.
- For an AI request, atomically reserve allowance using a stable operation ID. Competing requests cannot both spend the final credit.
- Settle once after the complete result is saved. A retry of that operation returns its existing status or result.
These are architecture recommendations, not a substitute for your billing SDK integration. Store purchase processing, app credit grants and AI-provider cost are three separate events.
Test restore and identity, not just the paywall
- Reinstall the app, sign in and restore using the supported platform flow.
- Sign out and into a different app account. Verify the documented transfer or ownership rule rather than inheriting another person’s access.
- Replay the same renewal event; the monthly grant is unchanged.
- Send two requests with one credit left; only one reservation succeeds.
- Let a result complete while the app is offline; reopening finds the saved result without a second charge.
- Verify expiry, cancellation and refund separately on the selected sandbox environments.
Native digital purchases must follow the current rules for the store, product type and storefront. Do not assume that this website’s email enquiry is a suitable payment flow inside a mobile app.
Inspect the zero-credit behavior
Open the Table Note demo and choose paid access and usage, then inspect the owned-report example. It illustrates reading an existing result at zero reply credits. Purchases, balances and replies are simulated; it does not exercise RevenueCat, StoreKit or Google Play Billing.
Bring your existing billing setup and the result users will buy to a launch-plan discussion. The first deliverable to agree is the state table, identity policy and acceptance path, followed by the required source integration.
References and scope
The flow and acceptance criteria are AppBento design recommendations. These primary references cover platform boundaries; they are not endorsements or evidence of native acceptance for the web demo.