Test Cases
Make sure your application passes the following test scenarios, if applicable, before going live.
Purchases
| No. | Test Case | Description | Expected Result |
|---|---|---|---|
| 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
| No. | Test Case | Description | Expected Result |
|---|---|---|---|
| 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
| No. | Test Case | Description | Expected Result |
|---|---|---|---|
| 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
| No. | Test Case | Description | Expected Result |
|---|---|---|---|
| 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 |