Testing

In test mode, you can run transactions with special testing values to verify your integration without actual money movement.

When you are testing your integration with Shift4, viewing request logs in your dashboard might be useful.

Our test numbers base on assumption that expiration date is any date in the future. CVC number consists of 3 or 4 digits of your choice unless testing cvc error (see the last position in Testing card processing errors).

When making requests in test mode, you must use one of the following cards to simulate a successful charge.

You can use one of the following card numbers to test validation errors in test mode. Errors can be simulated by creating a token, charge, or subscription.

In test mode, you can use one of the following card numbers to test various error responses. Errors can be simulated only by creating a charge or subscription. Note that creating a token won't return an error.

In test mode, you can test charge disputes by creating charges with one of the following cards:

Note that the charge created with one of those cards won't be disputed immediately after its creation. Usually, you need to wait about 1 minute for the charge to change its status to disputed.

When testing disputes, it is also possible to simulate different dispute flows. To do this, you must enter winning_evidence or losing_evidence text into the uncategorized_text field in API or additional details field in the dispute form in the dashboard.

In test mode, you can test fraud check by creating charges with one of the following cards:

In test mode, you can test 3D Secure by using one of the following cards:

In order to test ANI check, please use the following card number while performing the zero authentication:

And use the cardholder name from the following list:

In order to test AVS check, please use the following card number:

And use the zip code from the following list:

In order to test CCV check, please use the following card number:

And use the CCV from the following list:

In test mode, you can test credit by using one of the following cards:

You can simulate Apple Pay transactions without real card numbers, since tokens already include the required information. To create a test transaction, send one of the following tokens. Make sure to include the charge amount in the token. All transactions created with Apple Pay include a 3DS liability shift.

The tokens can be used in the payment method request body as follows:

{ "type": "apple_pay", "applePay": { "token": "TEST_TOKEN:100EUR" } }

The tokens can also be used in shift4.js in place of a real Apple Pay token, as shown below:

await shift4.createToken({
    methodName: 'https://apple.com/apple-pay',
    details: {token: {paymentData: 'TEST_TOKEN:1000EUR'}}
});

Want to lean more about Apple Pay? Visit Apple Pay integration example along with the technical specifications.

You can simulate Google Pay transactions without real card numbers, since tokens already include the required information. Note, that most card issuers require 3DS for Google Pay transactions. To create a test payment, use one of the tokens listed below:

• PAN_ONLY tokens – Merchants must run 3DS themselves.
• CRYPTOGRAM_3DS tokens – Already include the 3DS result provided by Google Pay.

For testing purposes, two special PAN_ONLY tokens do not support or require 3DS.

The tokens can be used in the payment method request body as follows:

{ "type": "google_pay", "googlePay": { "token": "CRYPTOGRAM_3DS" } }

The tokens can also be used in shift4.js in place of a real Google Pay token, as shown below:

await shift4.createToken({
    methodName: 'https://google.com/pay',
    details: {paymentMethodData: {tokenizationData: {token: 'PAN_ONLY'}}}
});

Find more about SCA and Google Pay API.

Want to lean more about Google Pay? Visit Google Pay integration example along with the technical specifications.

When you create PaymentMethod using account details received from customer it is not yet ready to be Charged. PaymentMethod would have status "pending". Verification process of such account can take up to a week. In Test mode account will be verified and PaymentMethod will became chargeable in a few seconds to simplify testing.

To finish test PaymentMethod setup one can enter following data:

And select account testing number from the following list:

Want to lean more about ACH? Visit ACH with bank account integration example and ACH with Plaid integration example along with the technical specifications.

Here are some testing examples for Blik with code number. When processing live with this method, payment results may take longer than in the test mode. For this reason, in test mode, you can use predefined codes to simulate success or failure, with different delays before the final result appears.

Want to lean more about Blik? Visit Blik integration example with full technical spec.

Here are some testing examples for phone number entry. When processing live with this method, payment results may take longer than in the test mode. For this reason, in test mode, you can use predefined codes to simulate success or failure, with different delays before the final result appears.

Want to lean more about Swish? Visit Swish integration example with full technical spec.