Testing Digital Wallet Payments - via API

Testing Card payments for your Digital Wallet payments via direct API integration:

Decline scenarios for wallet payments cannot be tested in the sandbox environment.

The payment or preAuth request can be sent with wallet details from Apple Pay™ or Google Pay™:

  • The payment token provided by the Apple Pay session.

  • The payment token generated by the Google Pay API.

 

Apple Pay™ PreRequisites

  • Before you can process Apple Pay™ payments and preAuths with Judopay, you will need to Set up Apple Pay™ to get your Merchant IDs.

  • To test Apple Pay™ payments and preAuths in sandbox, contact Support to configure your wallet payments credentials.

Google Pay™ PreRequisites

  • Before you can process Google Pay™ payments and preAuths with Judopay, you will need to Create a Google Pay Payments Profile to get your Merchant IDs.

  • To test Google Pay™ payments and preAuths in sandbox., contact Support to configure your wallet payments credentials.

 

Wallet Payment Scenarios (Positive Flow)

The digital wallet payment flow provides consumers with an extra layer of security, encrypting and decrypting the card details sent in the payload by replacing the consumer's card details with a device token, or dynamic security code.

 

What is the difference between DPAN and FPAN?

  • Device Primary Account Number (DPAN)

    • A device token is sent in the payload, instead of the card number.

    • SCA compliant.

  • Funding Primary Account Number (FPAN)

    • The card number is sent in the payload.

    • Requires 3D Secure 2 authentication to become SCA compliant.

      • Judopay's Transaction API triggers the 3D Secure 2 flow, to validate the transaction.

 

Important to Consider for Apple Pay™and Google Pay™(DPAN)

  • We recommend generating a unique Apple Pay™ and Google Pay™ payload for each test, to mimic the production environment where payloads can only be used once.

    If you want to re-produce test scenarios in the sandbox environment, you are able to use the same payload within a 24 hour time period before it expires

  • We do not recommend making Merchant Initiated Transactions using card tokens that were generated by Apple Pay™ or Google Pay™ DPAN. You may experience a lower transaction success ratio.

Apple Pay™ (DPAN)

  • Mobile and Web integrations

  • SCA compliant

  • For a successful end-to-end wallet payment testing journey, it is recommended to:

    • Perform wallet test scenarios in a production environment

    • Use live cards to process test payments and preAuths.

  • Ensure you have set up your Apple Pay™ certificate:

Google Pay™ (DPAN)

  • Mobile integration

  • SCA compliant

  • For a successful end-to-end wallet payment testing journey, it is recommended to:

    • Perform wallet test scenarios in a production environment

    • Use live cards to process test payments and preAuths.

  • The payload is the same when using Google Pay™ DPAN, or FPAN.

  • When sending the judoId in the payload to your Google Pay account, the field is displayed as gatewayMerchantId in the tokenization object

    For example, the value used in gatewayMerchantId is the same value as your judoId:

    • " judoId" :"100781350"

    • "gatewayMerchantId":"100781350"

 

Apple Pay™ and Google Pay™ (DPAN) Scenarios:

Suggested Test Scenario

Expected Outcome
Process an Apple Pay™ Wallet payment.

200

Successful

Process an Apple Pay™ Wallet preAuth.

200

Successful

Process a Google Pay™ Wallet payment.

200

Successful

Process a Google Pay™ Wallet preAuth.

200

Successful

 

Important to Consider for Google Pay™ (FPAN)

  • Web integration

  • Requires 3D Secure 2 authentication to become SCA compliant.

    • Judopay's Transaction API triggers the 3D Secure 2 flow, to validate the transaction.

    • For more details on the 3D Secure 2 flow, see 3D Secure 2 Flow.

  • To add your test card suite to your Digital Wallet to process test payments and preAuths, register your Google Pay Wallet.

    • Details for the cards in your test card suite are hard coded into the test wallet, therefore some negative scenarios cannot be simulated, due to limitations to Google Pay™s test environment. For example you cannot simulate an incorrect cv2, or insufficient funds.

    • You will only receive a success response.

    • No charge will be made on the test cards.

  • The payload is the same when using Google Pay™ FPAN, or DPAN.

  • When sending the judoId in the payload to your Google Pay account, the field is displayed as gatewayMerchantId in the tokenization object.

    For example, the value used in gatewayMerchantId is the same value as your judoId:

    • " judoId" :"100781350"

    • "gatewayMerchantId":"100781350"

  • We recommend generating a unique Google Pay™ payload for each test, to mimic the production environment where payloads can only be used once.

    If you want to re-produce test scenarios in the sandbox environment, you are able to use the same payload within a 24 hour time period before it expires.

 

Google Pay™ (FPAN) Scenarios:

Suggested Test Scenario

Expected Outcome Tip

Judopay's Transaction API triggers the 3D Secure 2 flow, to validate the transaction when sending the FPAN.

For each 3D Secure 2 scenario, different calls are made from the front end to the back end. Using a specific cardHolderName as specified in the CardHolderName Table, will correspond to an expected transaction result.

It is useful to have an understanding of the full 3DS 2 payment flow, including the conditional steps, to verify how it relates to the user journey in your app:

Process a Google Pay™ Wallet payment,

prompting the frictionless flow.

var googlePayConfiguration = {
        transactionMode: 'payment',
        scaExemption: null,
        challengeRequestIndicator: 'noChallenge'
 }

As the cardHolderName is hard coded in your test card suite, you will not be able to use this field to determine the 3D Secure 2 flow.

 

You will need to set the challengeRequestIndicator, to determine the frictionless flow.

Type of challenge request:

  • No Preference

  • No Challenge

Process a Google Pay™ Wallet payment,

prompting the non-frictionless flow.

var googlePayConfiguration = {
        transactionMode: 'payment',
        scaExemption: null,
        challengeRequestIndicator:'ChallengeAsMandate'
 }

As the cardHolderName is hard coded in your test card suite, you will not be able to use this field to determine the 3D Secure 2 flow.

 

You will need to set the challengeRequestIndicator, to determine the non-frictionless flow.

Type of challenge request:

  • Challenge Preferred

  • Challenge As Mandate

Process a Google Pay™ Wallet preAuth,

prompting the frictionless flow.

var googlePayConfiguration = {
        transactionMode: 'preAuth',
        scaExemption: null,
        challengeRequestIndicator: 'noChallenge'
 }

As the cardHolderName is hard coded in your test card suite, you will not be able to use this field to determine the 3D Secure 2 flow.

 

You will need to set the challengeRequestIndicator, to determine the frictionless flow.

Type of challenge request:

  • No Preference

  • No Challenge

Process a Google Pay™ Wallet preAuth,

prompting the non-frictionless flow.

var googlePayConfiguration = {
        transactionMode: 'preAuth',
        scaExemption: null,
        challengeRequestIndicator: 'ChallengeAsMandate'
 }

As the cardHolderName is hard coded in your test card suite, you will not be able to use this field to determine the 3D Secure 2 flow.

 

You will need to set the challengeRequestIndicator, to determine the non-frictionless flow.

Type of challenge request:

  • Challenge Preferred

  • Challenge As Mandate

For more information on API credentials and permissions, see Permissions.

 

Request Parameters

The payment or preAuth request can be sent with wallet details from Apple Pay™ or Google Pay™.

Sandbox endpoint: https://api-sandbox.judopay.com/transactions/payments

Sandbox endpoint: https://api-sandbox.judopay.com/transactions/preauths

HTTP Method: POST

 

Body Parameters:

 

Apple Pay™ Request Example:

For information on how to generate your token, see Apple Pay Payment Token.

 

 

Google Pay™ Request Example:

The payload is the same when using Google Pay™ DPAN, or FPAN.

For information on how to generate your token, see Google Pay Payment Token.

 

Response

 

Response Example:

 

Wallet Payment Scenarios (Negative Flow)

Decline scenarios for wallet payments cannot be tested in the sandbox environment.

Important to Consider:

  • How your app handles negative flows

  • Your customer's experience should a negative flow occur:

    • Logic to communicate error messages

    • Customise how your app responds

  • How to maintain application consistency

Limited test coverage is possible in the sandbox environment. The suggested negative test scenarios refer to model and processing error codes and information on why the transaction request failed Judopay's validation checks, which are similar to card payment scenarios.

Suggested Negative Test Scenario

Expected Error Code

Error Description

Attempt to perform a wallet payment / preAuth request with the Incorrect currency entered for the specified transaction.

 

Default currency = GBP

72

Sorry, we're currently unable to route this transaction. Please check your account details and try again.

If this issue persists, please contact customer services.

This is a processing error.

Attempt to perform a wallet payment / preAuth request with the incorrect environment (live or sandbox) for your API Token and API Secret and configuration.

7 Sorry, we were unable to authorize this request. Please check your details and permissions before trying again.

Where the codes remain fixed, the descriptions may change. You should not build any error handling logic based on these descriptions.

For a list of possible error codes, types and descriptions, see Error Codes and Descriptions

 

Next Steps

Using the response information from a successful wallet payment test transaction, you can test the following scenarios.

Directly call the Transaction API to make a: