Primer Sandbox Processor

Primer provides a Sandbox Processor that can be used in the Sandbox environment to make test payments and validate your integration.

This processor comes with:

• a set of test card numbers to trigger various scenarios
• a set of mocked payment methods to create your first payments on the checkout

Test card payments

For test card payments, you can use the following test cards to simulate scenarios:

Successful authorization

Use the following test cards to simulate a successful authorization.

Failed and declined authorization

Use the following test cards to simulate a failed or declined authorization.

Test mocked payment methods

The Primer Sandbox Processor bundles a mocked version of PayPal, Sofort and Klarna.

For each of these payment methods, you can trigger the desired outcome of the “Authorization” using the Drop-In Checkout.

Third-party processors & payment methods

Some payment methods and processors feature a sandbox/test environment. View the public documentation of these services to learn how to best leverage their environment.

Testing 3D Secure

For testing 3DS, you can use the following test cards to simulate scenarios:

The challenge screen will present options for you to choose your test response.

Testing fallbacks

To test fallbacks, you need:

• a test card that will decline or fail with your primary processor under one of the conditions outlined above
• a fallback processor that will authorize the payment based on the test card used to decline or fail with the first processor

Primer test processor

In sandbox, set the Primer test processor as the primary processor and an alternative processor as the fallback processor, such as Braintree, Stripe or Worldpay.

Failed and declined authorization

Use the following test cards to simulate a failed or declined authorization.

Use any 3-digit CVV and future expiry date to trigger the test scenario.

Using one of Primer's test cards for generic decline and fail authorizations above, the authorization request will decline or fail (depending on the card used) and trigger a fallback. The fallback authorization request should then be sent and be authorized.

Other sandbox processors

It's possible to test fallbacks without using the Primer test processor. You will need to review the testing guides for your processors and ensure:

• you can decline or fail a payment with your primary processor for the conditions outlined above
• the test card or test scenario can lead to a successful authorization request with your fallback processor

See below for some example processors and how to test fallbacks using them.

Braintree

Braintree enable authorization responses to be determined by the authorization amount. You can test fallbacks using Braintree as your primary processor.

Set Braintree as the primary processor and configure your fallback processor.

Then, create a test payment with the amount set to 3000.00-3000.99 and use any test card from your fallback processor that will result in an authorized payment.

The authorization will decline and trigger a fallback. The fallback request should then be sent and be authorized.

Worldpay

Worldpay enable authorization responses to be determined by the cardholder name. You can test fallbacks using Worldpay as your primary processor.

Set Worldpay as the primary processor and configure your fallback processor.

Then, create a test payment with the cardholder name set to "ERROR" and use any test card from your fallback processor that will result in an authorized payment.

The authorization will decline and trigger a fallback. The fallback request should then be sent and be authorized.

Stripe

Stripe enable authorization responses to be determined by the card number. You can test fallbacks using Stripe as your primary processor.

Set Stripe as the primary processor and configure your fallback processor.

Then, create a test payment with the card number 4000000000000119 and ensure this card will result in an authorized payment with your fallback processor.

The authorization will decline and trigger a fallback. The fallback request should then be sent and be authorized.

Testing fraud checks

To test fraud checks in sandbox, you will need to pass the right data to trigger the specific fraud check outcome you want to test. This will vary per fraud detection provider so ensure you check their documentation and our fraud provider specific documentation on what needs passing.

Testing network tokens

Provisioning network tokens

The best way to vault a card is to use Universal Checkout. Make sure to call POST/client-session with a customerId and vaultOnSuccess set to true. This automatically vaults the card if the payment is successfully authorized.

This first payment is processed using the raw card data. Once vaulted, it usually takes a few seconds for the network token to be provisioned and available for subsequent payments.

Use the following test cards to simulate scenarios:

To validate that the card was properly network tokenized, call GET/payment-instruments to list the saved payment methods for a specific customerId. The field paymentMethod.isNetworkTokenized is set to true when the network token was successfully provisioned and attached to the vaulted card.

Processing payments with network tokens

When a payment is created with a vaulted card that has been network tokenized, Primer automatically attempts to pass the network token to the processor, if the processor is supported.

You can test this by creating a payment with:

• the Payments API by following this guide
• or with the vault section of Universal Checkout, by selecting a vaulted card that was network tokenized

To validate that the payment used a network token, call GET/payments/{paymentId} with the payment ID to retrieve the payment object. The field cardTokenType is set to:

• NETWORK_TOKEN if the payment was processed with a network token
• CARD_PAN if the payment was processed with the raw credentials