Your first verified purchase

Follow this path for one store first, then repeat the store-specific steps for the other platform. You need a verified CherrySub account, access to your store app, a real sandbox/test purchase path, and a backend that authenticates your app's users.

The dashboard preview is at app-staging.cherrysub.com. Its runtime API is https://api-staging.cherrysub.com. Keep this deployment choice consistent in your backend, SDK, CLI, and notification configuration.

1. Create an account and project

Sign up, open the verification email, and finish verification. Use the initial project associated with your account, create an additional project if needed, or accept your team's invitation. The project switcher controls which apps and settings you see. An owner or admin performs configuration; a viewer can inspect the project.

If verification opens in a different browser, sign in there before continuing. Invitation and verification links preserve their local continuation. See accounts and projects.

2. Add your app

Open Apps → Add app. Choose App Store, Google Play, or both. For Apple, search for the public listing or enter its identifiers manually. For Google, enter the exact package name.

An Apple production app needs both its bundle ID and numeric App Store app ID. Save the newly displayed secret and publishable keys: plaintext keys are shown only once. Keep the secret on your backend and the publishable key in your client configuration.

Expected result: the app appears in Apps and can be selected in the project/app switcher. App configuration details.

3. Connect the store

Open Integrations → App Store or Google Play. Use Set up with CLI for guided provisioning, or Upload credential for an existing key.

cherrysub auth login
cherrysub setup apple APP_UUID --project PROJECT_UUID

Apple setup creates an In-App Purchase key after local sign-in, 2FA, team selection, and confirmation. Google automation currently requires your Desktop OAuth client; its command then provisions an app-specific service account and Play permissions.

Expected result: the page shows an app credential and masked account hint. This confirms credential storage, not a successful live purchase. Finish the store's notification setup using the Apple or Google guide.

4. Define products and access

Ensure the actual SKU exists in the store. In CherrySub, create an access level such as pro first. Then open Products → Register product, select the exact store/product ID, and choose pro plus the grant mode. Registration creates that explicit access mapping; you do not need to add the same mapping again.

For a normal subscription, use store_managed. Use lifetime only when access should have no scheduled expiry while still responding to verified revocation. Mapping changes apply from their event boundary; they do not replay old history with today's catalog.

Expected result: the product detail shows the access mapping. Products · Access levels.

5. Select a product set

Create a product set such as default, add packages for the products your purchase screen presents, and mark it as the app's current set. Give each package a unique identifier and position. The SDK reads that order and then asks the storefront for localized prices and purchase options.

Expected result: GET /v1/product-sets/current returns a non-null set. An empty current set or a missing platform package must produce an honest empty purchase screen, not a hard-coded fallback. Product sets.

6. Implement the token broker and SDK

Your authenticated backend calls POST /v1/client-tokens with iap_sk_. It chooses app_user_id from the verified application session, then returns only token and expires_at to the client.

Configure the SDK with iap_pk_, the runtime API URL, and a token provider. Follow authentication, then Swift, Android, Flutter, React Native, or Dart. A Go broker example is available.

Expected result: the client can obtain a token and read its current product set. A subscriber read may return 404 before the customer's first qualifying receipt; that is not permission to invent active access.

7. Make and verify a sandbox purchase

Purchase through a store-backed sandbox/test path. Submit StoreKit's transaction JWS or the Google purchase token. Google requests also name subscription or one_time_product.

Complete the store transaction only after CherrySub accepts the receipt. Read the subscriber again and check access_levels.pro.active.

In the dashboard, use the same app and the sandbox environment. Open Transactions, locate the purchase, inspect its customer, and verify the product mapping and active access. Then inspect the corresponding event evidence.

8. Exercise the rest of the lifecycle

Test a renewal, cancellation that remains active until expiry, refund/revocation, duplicate submission, restore under your intended account policy, logout/token invalidation, and a failed webhook receiver. Follow the test matrix.

You are ready for the next rollout stage when the storefront result, CherrySub transaction, customer access, and your application's protected feature agree. The dashboard setup checklist is a navigation aid; it is not a substitute for this end-to-end proof.