Testing scenarios

Create a test account Sign in to Dashboard System status
Search…
Testing scenarios
Learn how to test payment methods.
This page explains how to get started testing your payment integrations and provides links to the payment methods currently supported in our test environment. When testing standard payment methods, such as credit cards, we provide data you can use to test against success and error scenarios. We also provide information on how to test redirect and receiver type payment methods.
For details on evaluating VAT implementations, refer to the test tax identifiers section on the Tax identifiers page. 
Getting started
When evaluating your integration, always use your test API keys. This prevents you from interacting directly with payment services and 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 test payment sources in DigitalRiver.js, use your public test API key.
The testing approach you use depends on whether the payment method has a authentication flow of standard, redirect, or receiver. If you don't know the flow of the payment method you'd like to test, you can find it in the Supported payment methods section of the Drop-in page.  
Supported payment methods in test environment
The Digital River API supports a wide range of payment methods. Not all of them however are currently supported in our testing environment. You can find the test environment status of each payment method in the Supported payment methods section of the Drop-in page. 
Testing standard payment methods
The payment methods with a standard authentication flow 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, and use the appropriate data to set the parameters of the creditCard hash table.
Success scenarios
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 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
Error scenarios
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 state of the Source is failed.
4000 0000 0000 3600
A Source is successfully created but the Charge fails. The state of the Charge is failed.
4000 0000 0000 4103
Both a Source and Charge are successfully created , but the Capture fails. The Capture state is failed.
4000 0000 0000 4111
A Source, Charge, and Capture are successfully created, but the Refund fails. The Refundstate is failed.
4000 0000 0000 4442
Both a Source and Charge are successfully created , but the Cancel fails. The Cancel state is failed.
4485 9517 8852 1565
Both a Source and Charge are successfully created, but the Capture is created in a pending state.  After a delay, the Capture state updates to  failed.
4556 6025 6424 0839
A Source, Charge, and Capture are successfully created, but the Refund is created in apending state. After a delay, the Refund state updates to failed.
4024 0071 2057 9635
Both a Source and Charge are successfully created, but the Capture is created in apending state. The Capture state remains pending.
4000 0000 0000 0028
Both a Source and Charge are successfully created,  but the Capture is created in apending state. The Capture state remains pending.
Testing redirect payment methods
The following are the payment methods with a redirect authentication flow that Digital River currently supports in our testing environment: PayPal, SEPA Direct Debit, Klarna, IBP, and Alipay.
Success scenarios
For redirect payment sources, use the create source method 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 chargeable state
Decline
The Source remains in a pending_redirect state.
Error scenarios
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, set the lastName parameter in the Owner object to the value that you expect to trigger the scenario.
PayPal
SEPA Direct Debit
Klarna Credit
Alipay
The testing information on this tab is applicable to PayPal, PayPal Billing Agreement, and PayPal Credit.
lastName parameter
Expected result
SourceCreationFail
A Source is not created. The state of the Source is failed.
ChargeCreationFail
A Source is successfully created but the Charge fails. The state of the Charge is failed.
RefundFail
Both a Source and the Charge are successfully created but refunds against the Charge fail. The state of the Refund is failed.
lastName parameter
Expected result
SourceFail
A Source is not created. The state of the Source is failed.
SourceFailAfterRedirect
The Source moves to a state of failed after redirecting from payment page.
ChargeFail
A Source is successfully created but the Charge fails. The state of the Charge is failed.
ChargeFailedAfterPending
The Charge is initially created in a pending state. After a webhook call, the Charge is moved to a failed state.
RefundFail
Both a Source and the Charge are successfully created but refunds against the Charge fail. The state of the Refund is failed.
RefundFailedAfterPending
The Refund is initially created in a pending state. After a webhook  call, the Refund is moved to a failed state.
ChargeRemainPending
After a Charge is created, it remains in a state of pending.
lastName parameter
Expected result
SourceCreationFail
A Source is not created. The state of the Source is failed.
ChargeCreationFail
A Source is successfully created but the Charge fails. The state of the Charge is failed.
RefundFail
Both a Source and the Charge are successfully created but refunds against the Charge fail. The state of the Refund is failed.
lastName parameter
Expected result
authFail
A Source is not created. The state of the Source is failed..
authFailAfterRedirect
A Source is successfully created but the Charge fails. The state of the Charge is failed.
refundFail
Both a Source and the Charge are successfully created but refunds against the Charge fail. The state of the Refund is failed.
Testing receiver payment methods
Wire Transfer is currently the only payment method with a receiver authentication flow 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.
Success scenarios
For receiver type payment methods, use the create source method 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.
Error scenarios
From the following table, first identify the error scenario you would like to test against. Then when creating a source, set the lastName parameter in the Owner object to the value that you expect to trigger the scenario.
lastName parameter
Expected result
SourceCreationFail
A Source is not created. The state of the Source is failed.
SourceFailWithDelay
A Source is successfully created but the Charge fails. The state of the Charge is failed.
RefundFailWhileCreation
Both a Source and the Charge are successfully created but refunds against the Charge fail. The state of the Refund is failed.
RefundFailAfterPaymentInfo
Both a Source and the Charge are successfully created and a Refund request against the Charge is successful but ultimately fails to refund.
Building your workflows
Next - Administration
Dashboard
Last modified 1mo ago
Copy link
Contents
Getting started
Supported payment methods in test environment
Testing standard payment methods
Testing redirect payment methods
Success scenarios
Error scenarios
Testing receiver payment methods
Success scenarios
Error scenarios