Testing scenarios

Learn how to test different scenarios in your integration.

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.

Getting started

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.

Supported payment methods with flow type

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

standard

Google Pay

Supported

standard

Apple Pay

In progress

standard

PayPal

Supported

redirect

Direct Debit

Supported

redirect

Internet Bank Payment (IBP)

Supported

redirect

Klarna

Supported

redirect

Alipay

Supported

redirect

Korea - Bank Transfer

In progress

redirect

Wire Transfer

Supported

receiver

bPay

In progress

receiver

Konbini

In progress

receiver

Testing standard payment methods

The payment methods with a standard flow type that Digital River currently supports in our testing environment are Credit Cards and Google Pay.

Credit cards

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.

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 the following test data.

Card number

Brand

Expiration date

Security code

3714 4963 5398 431

American Express

03/2030

7373

4035 5014 2814 6300

Cartes Bancaires

03/2030

737

3056 9309 0259 04

Diners

03/2030

737

6011 1111 1111 1117

Discover

03/2030

737

3566 1111 1111 1113

JCB

03/2030

737

5454 5454 5454 5454

Mastercard

03/2030

737

6212 3456 7890 1232

UnionPay

03/2030

737

4485 1140 4115 6337

Visa

Any future date

Any three digits

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 4663

A Source, Charge and Capture are successfully created but the Refund fails. The Refund state is failed.

4000 0000 0000 4442

Both a Source and Charge are successfully created , but the Cancel fails. The Cancel state is failed.

Testing redirect payment methods

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.

Success scenarios

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 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 using DigitalRiver.js, set the lastName parameter in the Owner object to the value that you expect to trigger the scenario.

PayPal
Direct Debit
Klarna Credit
Alipay
PayPal

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.

Direct Debit

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 [Is this referring to an order.charge.failed webhook event?], 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 [Is this referring to an order.charge.refund.failed webhook event?], the Refund is moved to a failed state.

ChargeRemainPending

After a Charge is created, it remains in a state of pending.

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

Alipay

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

Success scenarios

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.

Error scenarios

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.

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.