Test Cases
Recommended testing scenarios you could work through before you go live. Skip any that do not apply to your app.
Use the Sandbox environment for testing, so nothing here counts against your quota.
Purchases
| # | Test | What to do | What should happen |
|---|---|---|---|
| 1 | Validation Success | Purchase a One-Time product | - You receive a successful response - The transaction is visible in the Application Details - Sandbox transaction did not reduce app quota |
| 2 | Validation Failed | Send a fake receipt or valid transaction from a different app | - You receive an error response - The transaction is not visible in the Application Details - You display a message to the user |
| 3 | Content Unlock | Unlock app content after purchase | - Your app can parse successful validations and unlocks content accordingly |
| 4 | Restore | Invoke the native transaction restore mechanism | - On re-install, purchases on the user's account are retrieved - Transactions are validated and unlock content again - If restore is not supported, you provide some other form of backup to claim back previous purchases |
Subscriptions
| # | Test | What to do | What should happen |
|---|---|---|---|
| 1 | Validation Success | Purchase a Subscription product | - You receive a successful response - The transaction is visible in the Application Details - Sandbox transaction did not reduce app quota |
| 2 | Validation Failed | Send an expired or declined receipt | - You receive an error response - The transaction is not visible in the Application Details - You display a message to the user |
| 3 | Content Unlock | Unlock app content based on status | - Your app can parse the current subscription status and unlocks or denies content accordingly |
| 4 | Refresh Status | Check subscription status every few minutes | - The subscription in user inventory gets updated - Your app understands different subscription status responses - You display a message to the user in case of billing issues - You remove content when the subscription expired |
Users
| # | Test | What to do | What should happen |
|---|---|---|---|
| 1 | Identifier | Set User ID | - Your authentication system works and correctly sets the User ID - Without authentication, you make use of validation response's User ID - The device returns the same User ID on subsequent logins |
| 2 | Inventory | Check user inventory | - Requesting user inventory returns all previous purchases, or empty - Consumable purchases are not listed |
| 3 | User Behaviour | Send same receipt multiple times from different User IDs | - Depending on selection in App Setup, validation is either blocked, user gets replaced or added - Verify that requests in cooldown period (Transfer) or above user limit (Alias) fail |
| 4 | Sandbox Storage | Check Transaction and User Inventory existence | - Depending on User Behaviour, re-validation is blocked or continues to return same response for one hour - User Inventory is not empty after purchase - After one hour, User Inventory is empty and transaction can be validated again |
Webhooks
| # | Test | What to do | What should happen |
|---|---|---|---|
| 1 | Response Data | Server receives webhook | - Your server successfully receives the webhook data and can read its contents |
| 2 | Data Processing | Server processes webhook | - Your integration successfully processes webhook data and writes expected outputs to your backend system, if any |