- Who is this for?
- Mobile teams implementing in-app purchases or subscriptions.
- Before you start
- Store sandbox accounts, product identifiers and transaction-to-account mapping.
1. Separate payment and entitlement
A store transaction belongs to a payment lifecycle. An entitlement records which feature a user may access now. A client-side boolean is not an authoritative record. Store the provider, product, transaction identity, account mapping and validity state on the backend. Protect verification material from logs and public fields.
2. Verify client claims
Treat client-submitted identifiers as inputs to verification, not proof. Use the store’s current server verification mechanism to confirm application, product and transaction state. Keep privileged credentials on the server. A retry after a lost response must not create a second entitlement for the same transaction.
3. Model transitions and duplicates
Renewal, cancellation, billing trouble, expiry and refund require distinct transitions. Cancellation can stop a future renewal without immediately ending the current period. Older or duplicate notifications must not overwrite newer authoritative state.
| Input | Decision |
|---|---|
| Verified purchase | Record and map transaction |
| Repeated transaction | Return previous result |
| Status notification | Verify authoritative state |
| Refund / expiry | Apply entitlement policy |
4. Combine events with reconciliation
Verify incoming notifications, persist an event identifier and queue longer work. Periodically reconcile selected transactions against store state to recover from missing events. Update entitlements from that result. Do not assume a notification body remains permanently accurate or that every notification arrives in order.
5. Test lifecycle failures
Exercise repeats, cross-account claiming, delayed notifications, renewal, refund and returning from offline mode. Check cross-device access, account changes and restore-purchase behavior. Store commissions and operational costs are separate from hosting.
- Enforce transaction uniqueness.
- Verify notification authenticity and application identity.
- Keep an audit of entitlement changes.
- Show a verification-pending state to users.
Action summary
- Separate transactions and entitlements.
- Trust verified store state.
- Test repeats, refunds and delays.
Common questions
Should cancellation revoke access immediately?
Not necessarily. Use the store state and the product’s explicit access-period policy.
Do notifications remove the need for reconciliation?
No. Periodic checks can recover missed or delayed updates.
Sources and scope
Technical references are listed below. Examples illustrate implementation in your own environment; they are not customer benchmarks or claims of live Uygulama Cloud services. Check the current provider documentation before applying settings.
Sources checked: