Testing¶
The partner can test the interaction before providing the product to clients.
Upon connection, the partner receives a siteId
, which is, by default, in the testing mode. In this mode, the partner can perform operations without actual money movement.
If the siteId
is in production mode, request to switch it to testing mode by contacting the support service or request to create a new one through a support manager.
After the testing is complete, the support service switches siteId
from testing to production mode.
- The API access key, which maps to a specific siteId, works for all payment methods connected to that identifier.
- When switching to production mode, there is no need to reissue the API Access Key.
The partner should use standard payment acceptance API URLs for testing.
Please note
Payment methods listed in the «Internet Acquiring» → «Payment Methods» are available for testing. Exception - Yandex Pay, Mir Pay, payment using a mobile phone balance, or QIWI Wallet.
Paying with a Bank Card¶
Rules and Restrictions¶
- Currency: Russian Ruble only (
amount.currency:643
). - Maximum transaction amount: 10 Rubles.
-
Maximum number of transactions per day: 100.
Transactions are counted for the current day (GMT+3).
-
Payment using a payment token is available.
The process of issuing a token for use in testing mode is the same as the process of issuing a token for use in a production environment.
Test Data¶
Card Expiry Date
Different card expiry dates are used for testing various payment processing results.
Use one of the month values listed in the table below. The card’s expiry year must be greater than the current year.
Month of Card Expiry | Payment processing result |
---|---|
02 | Transaction failed |
03 | Transaction successful with a 3-second delay |
04 | Transaction failed with a 3-second delay |
All other values | Transaction successful |
Card Numbers
Test card numbers are listed in the table below.
Payment System | Card Number |
---|---|
Mir | 2200000000000004 2200000000000012 2200000000000020 2200000000000038 2200000000000046 2200000000000053 2200000000000061 2200000000000079 2200000000000087 2200000000000095 2200000000000103 2200000000000111 |
Visa | 4256000000000003 4256000000000011 4256000000000029 4256000000000037 4256000000000045 4256000000000052 4256000000000060 4256000000000078 4256000000000086 4256000000000094 4256000000000102 4256000000000110 |
Mastercard | 5236000000000005 5236000000000013 5236000000000021 5236000000000039 5236000000000047 5236000000000054 5236000000000062 5236000000000088 5236000000000096 5236000000000104 5236000000000112 5236000000000120 |
UnionPay | 6056000000000000 6056000000000018 6056000000000026 6056000000000034 6056000000000042 6056000000000059 6056000000000067 6056000000000075 6056000000000083 6056000000000091 6056000000000109 6056000000000117 |
CVV
CVV can be any 3 digits.
Имя держателя карты
Any Latin characters.
3DS¶
Here, we describe the details of testing QIWI Form Payment with 3DS authentication.
During card detail input, use the data from the table below.
Parameter | Value |
---|---|
Card Number | Value from the «Test Data» section |
CVV | 849 |
Cardholder Name | A string containing 3ds |
After clicking the payment button on the form, an informational message with an option to confirm or decline the transaction appears. Authentication result depends on selected option.
Fast Payment System¶
Rules and Restrictions¶
-
Testing is only available for the following Payment API methods:
-
The set of statuses that can return for a request to get the payment status by QR code is limited to the list in the table below.
Status Description CREATED Payment created DECLINED Payment declined EXPIRED Payment expired
Test Data¶
Different transaction amounts in the amount.value
field are used for testing various payment processing results.
Amount | Payment processing results |
---|---|
200 | QR code created successfully |
Any value other than 200 | Transaction failed, QR code not created |
Payouts¶
Test Data¶
Different transaction amounts in the amount.value
field are used for testing various payout processing results.
Amount | Payment processing results |
---|---|
200.00 or 2.00 | The original payout request returns WAITING status, which means payout accepted for processing. Subsequent requests for payout status return COMPLETED status, which means payout is successful |
500.00 or 5.00 | Payout declined, DECLINED status |
510.00 or 5.10 | The original payout request returns WAITING status, which means the payout has been accepted for processing. Subsequent requests for payout status return DECLINED status, which means payout declined |
Notifications¶
The partner can switch notification receiving URL from production to test and vice versa in the personal account.