Testing scenarios
Gain a better understanding of how to test your payments integration
To confirm that the payment methods in your integration work as expected, you can simulate transactions without transferring any money.
On this page you'll find information on:
For details on evaluating VAT implementations, refer to the test tax identifiers section on the Tax identifiers page.
Getting started
Always use your test API keys to evaluate your integration. This prevents direct interactions with payment services and ensures that input data doesn't result in the creation of an actual charge or the transfer of funds.
When testing in the Digital River APIs, use your confidential (secret) and your public test key to create payment sources in DigitalRiver.js and DigitalRiverCheckout.js.
How you test a payment method depends on whether its resulting source has an authentication flow of standard, redirect, or receiver. If you don't know this, you can find it on the Supported payment methods page.
Payment methods supported in the test environment
Digital River supports a wide range of payment methods. However, not all of them are currently supported in our test environment. To determine the test environment status of each, refer to Supported payment methods.
Testing standard payment methods
In this section, you'll find information on testing payment methods whose resulting source has a standard authentication flow.
Credit cards
The following card numbers are only valid for testing. They do not create a real charge or result in a transfer of funds.
Success scenarios
To test a successful payment, use the following credit card numbers. Each's expiration date must be at least one day. Except for Visa and American Express, the security code can be any random three-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 |
Use the following data to test how your integration handles different 3D Secure 2 authentication scenarios.
| 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 card numbers to test specific error scenarios. For each card:
The expiration date must be at least one day in the future
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 4111 | 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 |
4485 9517 8852 1565 | Both a Source and Charge are successfully created, but the Capture is created in a |
4556 6025 6424 0839 | A Source, Charge, and Capture are successfully created, but the Refund is created in a |
4024 0071 2057 9635 | Both a Source and Charge are successfully created, but the Capture is created in a |
4000 0000 0000 0028 | Both a Source and Charge are successfully created, but the Capture is created in a |
Google Pay testing
Before you test Google Pay, you need to:
Have a Google Account.
Join the Google Pay API Test Cards Allowlist group. Once you've joined, a test card suite is enabled in your Google account.
Any credit card in this suite can create a source, charge, capture, and refund.
However, the customer's last name must be a specific value to evaluate whether your application properly handles failures and Strong Customer Authentication. Use the table below to determine the scenario you want to test and the value that triggers the behavior.
Digital River's low-code checkout solutions don't currently support testing Google Pay failures and SCA.
| Scenario | Last name |
|---|---|
The source is created but its | SourceFail |
ChargeFail | |
CaptureFail | |
CancelFail | |
RefundFail | |
The source is successfully created and the user is challenged | SCATest |
SCATestFail |
Testing redirect payment methods
You can use the information in this section to test success and error scenarios on payment methods whose resulting source has a redirect authentication flow.
Success scenarios
Use the create source method to provide success scenario test data for redirecting payment sources. 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 |
Error scenarios
First, select one of the following payment methods for redirect sources. 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 you expect to trigger the scenario.
This tab's testing information applies 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 |
Testing receiver payment methods
You can use the information in this section to test success and error scenarios on payment methods whose resulting source has a receiver authentication flow.
Work with your support team when testing wire transfers. They can provide instructions on how to move your orders into a completed state.
Success scenarios
Use the create source method for receiver-type payment methods to provide success scenario test data. Once you've done this, you should receive a Source in a pending_funds state. You can then use the Source to complete your Checkout or Order.
Error scenarios
First, identify the error scenario you would like to test against from the following table. Then when creating a source, set the lastName parameter in the Owner object to the value you expect to trigger the scenario.
| Scenario | Description |
|---|---|
| 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. |
Testing the CCAvenue payment method
Use the following when testing in the CCAvenue sandbox:
| Payment option | Payment information | Notes |
|---|---|---|
Credit Card | 4111111111111111 / 123 | The expiration date must be at lease one day in the future. |
Net Banking | AvenueTest | |
UPI | select BHIM (first button) / 123456@upi | Wait for the countdown. Unified Payment Interface (UPI) identifier can be any six-digit number and @upi—for example, 123456@upi and 458093@upi. You can use every UPI identifier multiple times per day. However, when testing, you should either (1) clear the cookies or (2) use an incognito window every time after placing the order. |
Wallet | AvenueTest |
Success and error scenarios
To test for successful or failed payment scenarios, use any card number available under Testing CCAvenue. Visit the Bank Response Page via the following URL https://test.ccavenue.com/bnk/servlet/processCCardReq?gtwID=AVN&requestType=PAYMENT to specify the card's behavior. Before running the test scenario, complete the necessary fields and set the Transaction Status to Y for a success scenario and N for an error scenario.
Production testing best practices
To conduct end-to-end testing of your financial systems before going live, you'll need to use our production environment. This is because Digital River's financial APIs, which can be used to access sales transactions, sales summaries, and payouts, aren't supported in test mode. As a result, you can't configure a webhook in this mode to listen for events with a type of sales_transaction.created and payout.created.
Here are some guidelines to follow when testing in production:
Keep the volume of transactions and their monetary value to a minimum to avoid heavy impacts on your financial reporting.
Pass "real" data (i.e., actual card numbers, names, emails, and addresses).
Don't use the test data contained in this article. Doing so might negatively affect your authorization rates, trigger manual reviews of transactions by Digital River, and result in fraud blocks being placed on the order's email address.
Ensure that your transactions are flowing through the proper fraud system. There's no way for you to configure the JavaScript libraries or APIs to control this flow. So, before doing live testing, notify your Digital River representatives and they'll work with our fraud team to get everything set up correctly.
Provide your Digital River representative with any data you'd like positive or negative listed. For example, you can provide us with email addresses that represent "good" customers. We'll then add those emails to a positive list. When orders with those values enter our fraud system, we'll let them pass through without any checks. Alternatively, you might want orders with certain IP addresses to be held for fraud review or rejected outright. If that's the case, you can give us a list of those addresses and we'll add them to a negative list.
Last updated
