Testing scenarios

Learn how to test payment methods.

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) test key 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. For each, the expiration date must be at least one day in the future. With the exception of Visa and American Express, the security code can be any random three-digit number.

Card numberBrandExpiration dateSecurity 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

To test how your integration handles different 3D Secure 2 authentication scenarios, use the following data.

Card numberBrandExpiration dateSecurity 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 typePassword

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 NumberExpected 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.

Google Pay testing

Before you test Google Pay, you need to:

Any of the credit cards in this suite can be used to successfully create a source, charge, capture and refund.

However, to evaluate whether your application properly handles failures and Strong Customer Authentication, the customer's last name must be a specific value. 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.

ScenarioLast name

The source is created but its state is failed

SourceFail

The source is successfully created but the charge's state is failed

ChargeFail

Both the source and charge are successfully created but the capture's state is failed

CaptureFail

The source and charge are successfully created by the cancel's state is failed

CancelFail

The source, charge, and capture are successfully created but the refund's state is failed

RefundFail

The source is successfully created and the user is challenged

SCATest

The source is successfully created and the user is challenged but the charge's state is failed

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 redirect 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:

OptionExpected result

Approve

The Source moves to a chargeable state

Decline

The Source remains in a pending_redirect state.

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.

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.

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.

ScenarioDescription

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.

Testing the CCAvenue payment method

Use the following when testing in the CCAvenue sandbox:

Payment optionPayment informationNotes

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 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 with a list of those addresses and we'll add them to a negative list.

Last updated