Testing Purchases
How to test RevenueCat Web purchase flows
Before shipping RevenueCat Web purchase flows, test both the purchase surface and the billing engine behind it. RevenueCat Web Billing uses Stripe as a payment gateway and works with Stripe's Test Mode and Sandboxes. Stripe Billing and Paddle Billing each use their own provider sandbox setup.
If you're using Stripe's Sandboxes, you'll need to set up a dedicated config for testing. See how to use a sandbox to test web purchases here.
For Stripe Billing, use a dedicated Stripe Sandbox config in RevenueCat. See Stripe Billing testing.
For Paddle Billing, use a Paddle sandbox account and a matching RevenueCat Paddle config. See Paddle Billing testing.
In contrast to mobile app stores, there is no intermediary between you and the customer, and no App Review before you start charging customers money. Therefore, you should make sure that you have properly tested your implementation in sandbox mode before shipping production web purchases, especially if you're using Redemption Links, which will require a mobile app update (read more)
Testing Web Purchase Links
Since sandbox URLs can be tied to real entitlements, you should never share them externally or with users.
If you're using RevenueCat Web Billing with a Stripe account that supports Test Mode: Web Purchase Links will display a separate production URL as well as a sandbox URL for testing.
If you're connected to a Stripe Sandbox: RevenueCat will only show a sandbox URL for your Web Purchase Link.
For Web Billing with Stripe Test Mode, the sandbox URL is automatically configured to use Stripe's Test Mode and works with Stripe test cards. For Stripe Billing or Paddle Billing, use the test cards and sandbox behavior for the provider account connected to the web config.
Testing Wallet Payment Methods
For both Apple Pay & Google Pay, you can use real payment cards in sandbox mode. Stripe automatically handles processing of wallet payment methods in a test mode, so no real transactions are made.
Subscription Schedules in Sandbox
Sandbox subscriptions in Web Billing renew faster than actual subscriptions to facilitate testing. They can renew a maximum of six times before being automatically cancelled.
The following table lists the sandbox renewal periods for subscriptions of various durations. These times are approximate, and you may see small variations. To ensure accuracy, check the current status after each subscription expiration.
Subscription Renewal Periods
| Production Subscription Period | Sandbox Subscription Period |
|---|---|
| 1 day (P1D) | 5 minutes |
| 3 days (P3D) | 5 minutes |
| 1 week (P1W) | 5 minutes |
| 2 weeks (P2W) | 5 minutes |
| 1 month (P1M) | 5 minutes |
| 2 months (P2M) | 10 minutes |
| 3 months (P3M) | 15 minutes |
| 6 months (P6M) | 30 minutes |
| 1 year (P1Y) | 60 minutes |
Time-based Subscription Features
Time-based subscription features such as free trials are also shortened for sandbox testing. The following table identifies the sandbox time periods associated with these features:
| Feature | Sandbox Period |
|---|---|
| Trial duration | 5 minutes |
| Introductory period duration | 5 minutes |
| Grace period duration | 3 minutes |
| Billing retries | Every 3 minutes and up to 5 attempts |