Testing SDK Pay Payments in the RuStore Console
Testing Pay SDK payments and subscriptions is only available in the RuStore environment. Testing payments outside of RuStore — without authentication or when the RuStore app is not installed — is not supported.
To test payments:
-
Make sure Test Mode is enabled.
After switching to Test Mode, you may need to wait a few minutes or restart your application (if it was already open) for the changes to take effect.
-
If you are not yet signed in RuStore on the testing device, log in using the VK ID under which you are registered in RuStore as a tester of this application.
-
Open (or install) the application on your device if you have not done so already.
-
Make a purchase in the application. For example, purchase an in-game item or a subscription.
During checkout, a payment window will appear with the “Test Purchase” label.
cautionIf the “Test Purchase” label does not appear, you are making the purchase in a non-test environment (the working/production version of the application). Make sure that Test Mode is enabled and you are signed in to the RuStore mobile app using the correct VK ID.
-
Tap Pay and choose the testing scenario.
-
If the successful scenario is chosen, verify that the payment went through successfully and that the application processed the purchase.
tipTest payments automatically appear in the RuStore Console under Monetization → Test Payments once the payment is complete.
cautionIf the payment went through successfully but you still do not see the purchased content in the app, check your own implementation logic. If you are experiencing other scenario-related issues, contact technical support at support@rustore.ru.
-
If the unsuccessful scenario is chosen, verify that an error message is displayed indicating that the payment cannot be completed.
Viewing Test Payments in the RuStore Console
To view the history of test payments:
- Open the RuStore Console.
- In the top menu, select Apps, then open the test application.
- Go to the Monetization → Test Payments tab.
On the Payment History tab, you will see all the payments that have been made in Test Mode. Functionally, this section mirrors Manage Payments, which shows purchases made by users in the production version of the application.
The Payment History tab allows you to:
-
Switch between SDKs using the toggle at the top of the tab to choose payments for the corresponding SDK (Pay or BillingClient).
-
View detailed information about each payment by clicking on it.
-
Filter payments by:
- amount – specify the minimum and maximum amounts (only one of these parameters is required);
- status;
- order number;
- date – click the filter again and select a date range to specify the needed period. By default, the filter displays all payments from the start of the calendar month.
Test subscriptions
Test subscriptions let you check the full cycle of recurring charges: from initial activation to renewals and handling failed payments.
Open Monetization → Testing → Test subscriptions.
Subscriptions list. Each row shows the current state of a subscription and the next billing event:
-
Purchase ID.
-
Activation date and Active until.
-
Auto-renewal: on/off.
-
Upcoming payment: the expected result of the next charge — Successful / Failed.
-
Period:
- free — free trial period.
- introductory — subscription period with a promo price.
- main — main period with regular recurring charges.
- grace — grace period after a failed charge attempt, during which the subscription is still considered active, but the payment has not yet been captured. User access is preserved, and the system continues trying to charge the user.
- hold — period during which the subscription is considered inactive because payment cannot be charged. Access to the subscription is lost, but charge attempts continue.
-
Status:
- active — the subscription is active.
- paused — the subscription is paused due to payment issues.
- stopped — all charge attempts for the subscription have been exhausted (all failed). The subscription is automatically closed due to payment issues.
- canceled — the subscription was canceled by the user or the developer. The paid period has ended, and the subscription is closed.
Filters and search. Use the chip filters above the table to filter by status, activation date, product code (and, if needed, by period, title, and description). Search works by purchase identifier (purchase id).
Subscription details. Clicking a row opens a card with a snapshot of the case:
- Technical information: subscription code, purchase ID.
- Upcoming payment: date/amount and expected result.
- Subscription: active until, period, auto-renewal.
- Payments: list of payments (successful, declined, refunded) with dates.
Actions. In the “⋯” menu (and on the details card), you can turn off auto-renewal to test how your app responds to renewal cancellation.
Limitations and test mode settings for subscriptions
- Access and activation. Sandbox subscriptions are only available to authorized users with test mode enabled. The subscription management section is only available to users with the following roles: company owner, administrator, finance manager. You can test unpublished subscriptions.
- Payment scenarios. At the payment step in the SDK, two outcomes are available: successful (subscription is created) and failed (subscription is not created).
- Auto-renewals and periods. By default, up to 10 charges are performed at 10-minute intervals. If additional periods are configured, they are applied sequentially: 1 charge in the free period, 1 in the introductory period, then N in the main period.
- Free/introductory periods are available for every test purchase for convenience. For real subscriptions, free/introductory periods are granted once per user.
- Server notifications and validation. Server notifications are sent for test payments (including failed ones). Server-side validation of test subscriptions is not yet available and will be added later.
- Data scope and access. The section shows only subscriptions for the current app. Available for apps that use Pay SDK.