This page explains how to get started testing your integration. It lists the payment methods currently supported in our test environment and their flow type. For testing standard payment methods, such as credit cards, you'll find data you can use to test against success and error scenarios. You'll also find information on how to test redirect and receiver type payment methods.
Always use your test API keys when testing. That way you never interact directly with the payments services. This ensures that the test data you enter does not create an actual charge or result in the transfer of funds.
When conducting testing in the Digital River API, use your confidential (secret) test API key. To create payment sources in DigitalRiver.js, use your public test API key.
The testing approach you use depends on whether the payment method has a flow type of standard, redirect, or receiver. If you don't know the type of the payment method you'd like to test, you can find it here.
The Digital River API supports a wide-range of payment methods. However, not all of these methods are currently supported in our testing environment. The following table indicates whether each payment method is supported or in progress.
We will update this list as payment methods transition to supported.
The table also indicates the flow type. The three types (standard, redirect, and receiver) are tested using different approaches.
Payment Method | Test environment status | Flow type |
​Credit Cards | Supported |
|
​Google Pay ​ | Supported |
|
Apple Pay | In progress |
|
​PayPal​ | Supported |
|
​Direct Debit | Supported |
|
​Internet Bank Payment (IBP) | Supported |
|
​Klarna ​ | Supported |
|
​Alipay ​ | Supported |
|
Korea - Bank Transfer | In progress |
|
​Wire Transfer ​ | Supported |
|
bPay | In progress |
|
Konbini | In progress |
|
The payment methods with a standard
flow type that Digital River currently supports in our testing environment are Credit Cards and Google Pay.
Before accepting live payments, you can use the card numbers in this section to test against success and error scenarios. These numbers are only valid in our testing environment. They do not create a real charge or result in a transfer of funds.
To conduct the testing, create a source in DigitalRiver.js, and use the appropriate data to set the parameters of the creditCard
hash table.
To test a successful payment, use the following basic credit card numbers. The expiration date must be at least one day in the future. With the exception of Visa, the security code can be any random three or four digit number.
Card number | Brand | Expiration date | Security code |
3434 567890 12341 | American Express | Any future date | Any four digits |
3034 567890 1235 | Diners Club | Any future date | Any three digits |
6011 9876 9876 9876 | Discover | Any future date | Any three digits |
3528 9876 9876 9879 | JCB | Any future date | Any three digits |
5466 1600 0000 0008 | Mastercard | Any future date | Any three digits |
6226 2200 0000 0009 | UnionPay | Any future date | Any three digits |
4444 2222 3333 1111 | Visa | Any future date | 123 |
You can also test how your integration handles different 3D Secure 2 authentication scenarios. To test your 3D Secure 2 integrations, use the the following test data.
Card number | Brand | Expiration date | Security code |
5454 5454 5454 5454 | Mastercard | 03/2030 | 737 |
4917 6100 0000 0000 | Visa | 03/2030 | 737 |
When prompted for 3D Secure 2 text challenges, use these credentials:
App type | Password |
Mobile | 1234 |
Web | password |
Use these test card numbers to test against specific error scenarios. For all the cards listed, the expiration date must be at least one day in the future and the security code can be any random three digit number.
Card Number | Expected result |
4000 0000 0000 3295 | A Source is not created. The |
4000 0000 0000 3600 | A Source is successfully created but the Charge fails. The |
4000 0000 0000 4103 | Both a Source and Charge are successfully created , but the Capture fails. The Capture |
4000 0000 0000 4663 | A Source, Charge and Capture are successfully created but the Refund fails. The Refund |
4000 0000 0000 4442 | Both a Source and Charge are successfully created , but the Cancel fails. The Cancel |
The following are the payment methods with a redirect
flow type that Digital River currently supports in our testing environment: PayPal, Direct Debit, Klarna, and Alipay.
For redirect payment sources, use the create source method in DigitalRiver.js to provide success scenario test data. Once you've done this, you should receive a Source in a pending_redirect
state.
You'll then be directed to our generic authorization page that contains accept and reject options. Follow the redirect and select one of the following options:
Option | Expected result |
Approve | The Source moves to a |
Decline | The Source remains in a |
For redirect sources, first select one of the following payment methods. Then identify the error scenario you would like to test against. Finally, when creating a source using DigitalRiver.js, set the lastName
parameter in the Owner object to the value that you expect to trigger the scenario.
The testing information on this tab is applicable to PayPal, PayPal Billing Agreement, and PayPal Credit.
| Expected result |
SourceCreationFail | A Source is not created. The |
ChargeCreationFail | A Source is successfully created but the Charge fails. The |
RefundFail | Both a Source and the Charge are successfully created but refunds against the Charge fail. The |
| Expected result |
SourceFail | A Source is not created. The |
SourceFailAfterRedirect | The Source moves to a |
ChargeFail | A Source is successfully created but the Charge fails. The |
ChargeFailedAfterPending | The Charge is initially created in a |
RefundFail | Both a Source and the Charge are successfully created but refunds against the Charge fail. The |
RefundFailedAfterPending | The Refund is initially created in a |
ChargeRemainPending | After a Charge is created, it remains in a |
| Expected result |
SourceCreationFail | A Source is not created. The |
ChargeCreationFail | A Source is successfully created but the Charge fails. The |
RefundFail | Both a Source and the Charge are successfully created but refunds against the Charge fail. The |
| Expected result |
authFail | A Source is not created. The |
authFailAfterRedirect | A Source is successfully created but the Charge fails. The |
refundFail | Both a Source and the Charge are successfully created but refunds against the Charge fail. The |
Wire Transfer is currently the only payment method with a receiver
flow type that Digital River supports in our testing environment.
You should coordinate with your support team when testing wire transfers. They can provide instructions on how to move your orders into a completed state.
For receiver type payment methods, use the create source method in DigitalRiver.js to provide success scenario test data. Once you've done this, you should receive a Source in a pending_funds
state. The Source may then be used to complete your Checkout or Order.
From the following table, first identify the error scenario you would like to test against. Then when creating a source using DigitalRiver.js, set the lastName
parameter in the Owner object to the value that you expect to trigger the scenario.
| Expected result |
SourceCreationFail | A Source is not created. The |
SourceFailWithDelay | A Source is successfully created but the Charge fails. The |
RefundFailWhileCreation | Both a Source and the Charge are successfully created but refunds against the Charge fail. The |
RefundFailAfterPaymentInfo | Both a Source and the Charge are successfully created and a Refund request against the Charge is successful but ultimately fails to refund. |