GenerateSaaSBilling
Store events and rules
What each store event does to a plan, the store review rules the app satisfies, and sandbox testing.
RevenueCat delivers every store event to your server, which owns the plan. The app renders what the server answers and never grants anything itself.
What an event does
| Store event | Effect |
|---|---|
| Initial purchase, renewal | Grants or extends the plan |
| Product change | Moves the plan; a downgrade lands at period end |
| Cancellation | Funded to the end of the period, then expires |
| Refund, chargeback | Revokes what that transaction granted |
| Credit pack | Grants its credits once per transaction |
| The nightly expiry sweep | Spares a lapsed store row 48 hours where it carries store ledger history, so the reconcile can adopt it |
Effects are idempotent: the same event delivered twice grants once.
Store rules
| Rule | Why |
|---|---|
| Digital goods are bought in-app | A website checkout link is rejected |
| Every signed-in user reaches the paywall | A paywall behind a web purchase fails review |
| Restore purchases is always offered | Both stores require a restore path |
| Manage and cancel are shown | The store's surface, or the Customer Center when config.payment.mobile.customerCenter is on |
| The external purchase link ships off | On "us-only" it shows for a self-funded holder of a plan the store did not sell, on a US storefront, and its tap opens the disclosure a store requires, not the browser |
Sandbox testing
config.payment.mobile.allowSandboxEvents decides whether a sandbox purchase takes effect on a deployment running as production, such as staging.
Never set it on the deployment your customers use. It is a checked-in constant with no environment override, and a sandbox event accepted there grants a real plan nobody paid for.