Testing your Integration
...
Testing your Wallet Payment In...

Testing Digital Wallet Payments - via Web SDK

Testing Digital Wallet Payments - via Web SDK

Make sure you are using Web SDK Version 0.0.18 (or higher).



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

Testing Card payments for your Digital Wallet payments via Judopay's Web SDK integration:

Apple Pay™ Prerequisites

From the Web SDK integration guide:

The payment form iFrame must be loaded onto the page in order for payments to work. However displaying the form to the consumer is not required for this transaction type.

Direct from Judopay:

  • Judopay JudoId
  • A valid apple-developer-merchantid-domain-association

From the Merchant:

  • Domain(s) being used for Apple Pay™
  • These are the domain(s) where the Apple Pay™ button will be displayed, for example the checkout page.

These must be SSL enabled domains, Apple will not allow non-encrypted domains to be used.

  • Account(s) being used for Apple Pay™

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.


Google Pay™ PreRequisites

From the Web SDK integration guide:

The payment form iFrame must be loaded onto the page in order for payments to work. However displaying the form to the consumer is not required for this transaction type.

Direct from Judopay:

  • Judopay Account (sandbox and eventually live)
  • Judopay JudoId

Merchant Requirement (Google Requirement): Prior to going live with Google Pay™ Web Payments, you must have a valid Google verified Live Merchant ID.

To receive your Live Merchant ID:

  1. Follow Google Pay™'s Integration Checklist, to ensure you have completed all the required steps in your integration.
  2. Begin the process to obtain production access from Google, here.

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.


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.

Apple Pay™ and Google Pay™ 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

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



Calling the Web SDK Functions

Apple Pay™ Configuration Object Parameters

paymentRequestApplePay

Parameter

Description

judoId String Required





Unique ID supplied by Judopay.

Specific to a merchant and/or location. Format:

  • 100100100
  • Maximum length 9 characters.
  • Do not include spaces or dashes.

amount Decimal Required





The amount to process. Format:

  • Two decimal places

For currencies using a different structure please contact Judopay for support.

currency String Required





The currency of the transaction.

Any ISO 4217 alphabetic currency code:

  • GBP
  • USD
  • EUR

yourConsumerReference String Required

Unique reference to anonymously identify your customer.

Advisable to use GUIDs.

Must be below 40 characters.

yourPaymentReference String Required





Your unique reference for this payment. Format:

  • Maximum length 50 characters.

This value should be unique in order to protect your customers against duplicate transactions.

With a server side integration, if a payment reference is not supplied, the transaction will not be processed.

initiativeContext String Optional

Your fully qualified domain name associated with your Apple Pay Merchant Identity Certificate.

  • The default is: window.location.hostname
  • For example: initiativeContext ="web.judopay.com"

methodConfiguration Object Optional

This parameter contains the following fields:

  • version
    • number
  • supportedNetworks
    • array containing any of the following strings:
      • “amex”
      • “chinaUnionPay”
      • “discover”
      • “masterCard”
      • “visa”
      • “maestro”
      • “jcb”
  • merchantCapabilities
    • array containing any of the following strings:
      • "supports3DS"
      • "supportsCredit"
      • "supportsDebit"
      • "supportsEMV"
  • countryCode
    • string

details Object Optional



Provides information about the specific transaction. Use this object to supply the information for recurring payments.

For more information, see Apple Pay™ Recurring Payments .

See here for more details on the parameter fields.

options Object Optional

Enables you to set options to control the behaviour of the user agent.

See here for more details on the parameter fields.

onShippingAddressChange Method Optional

Dispatched when the user changes their shipping address.

See here for more details on this parameter.

onShippingOptionChange Method Optional

Dispatched when the user changes a shipping option.

See here for more details on this parameter.

delayedAuthorisation Boolean Optional

For preAuths only.

Set to true to authenticate a card holder with 3D secure, without performing payment authorisation.

When set to true, the 3D Secure authentication status is returned in the response.

The payment authorisation is carried out at the stage when you are ready to collect the amount from the customer.

  • The default value = false

initialRecurringPayment Boolean Optional

Indicates if this initial payment is part of a recurring payment.

For more information, see Apple Pay™ Recurring Payments .



Google Pay™ Configuration Object Parameters

paymentRequestGooglePay

Parameter

Description

judoId String Required





Unique ID supplied by Judopay.

Specific to a merchant and/or location. Format:

  • 100100100
  • Maximum length 9 characters.
  • Do not include spaces or dashes.

amount Decimal Required





The amount to process. Format:

  • Two decimal places

For currencies using a different structure please contact Judopay for support.

currency String Required





The currency of the transaction.

Any ISO 4217 alphabetic currency code:

  • GBP
  • USD
  • EUR

yourConsumerReference String Required



Unique reference to anonymously identify your customer.

Advisable to use GUIDs.

Must be below 40 characters.

yourPaymentReference String Required





Your unique reference for this payment. Format:

  • Maximum length 50 characters.

This value should be unique in order to protect your customers against duplicate transactions.

With a server side integration, if a payment reference is not supplied, the transaction will not be processed.

paymentSession String Required









A unique string that references the payment session of this transaction.

The paymentSession will expire in 30 minutes, unless an expiryDate is set in the /paymentsession request body.

To get the reference:

  • Use any Google Merchant ID when creating a Google Pay™ transaction request in sandbox.

Use your verified Live Merchant ID when creating a live Google Pay™ transaction request.

  • Choose from the following transaction modes:
    • payment
    • pre_auth
  • Use the paymentSession response reference to populate this field.

transactionMode String Required

Represents type of transaction. Values:

  • payment
  • pre_auth

onSuccess Function Required





Set as the function you want called when the transaction is successful.

The response object will be passed as a parameter.

For more information on how to handle the response, Testing Digital Wallet Payments - via Web SDK.

onError Function Required





Set as the function you want called when there is an error.

The error object will be passed as a parameter.

For more information on how to handle the response, see Testing Digital Wallet Payments - via Web SDK.

paymentRequest Object Required





Use this to configure your site's support for the Google Pay™ API. For more information on this parameter and the fields it can contain, see PaymentDataRequest.

(For example, if you Include the optional flags, such as emailRequired (default=true), this will affect whether the related information (e.g. the Google Pay email) is available in the result object, which is returned when the transaction is complete).

You are required to provide the following mandatory fields:

    • To process payments, set the merchantId attribute in this object.
      • Use the merchantId provided after registering with Google Pay™. This is a requirement for processing a Google Pay™ payment in PRODUCTION.
    • The only mandatory attribute to be provided: parameters.allowedCardNetworks

The example paymentRequest object snippet in Step One, shows the fields that must be provided. (Judopay will provide the other required fields).

environment String Optional

Represents the environment type Google Pay™ will run in. Values:

  • PRODUCTION
  • TEST

buttonStyle Object Optional

Change the style of the Google Pay™ Button.

For more details on the fields you can set, see Google Pay Button Style .

onPaymentDataChanged Function Optional

Used when payment data changes in the payment form, for example:

  • shipping address
  • shipping options

For more information on this parameter, see onPaymentDataChanged.

onPaymentAuthorized Function Optional



Used when a payment is authorized in the payment form.

For more information on this parameter, see onPaymentAuthorized.

onReadyToPayChange Function Optional







Used when the consumer's isReadyToPay state changes.

Change the application's behaviour, based on whether or not the consumer is ready to pay.

When existingPaymentMethodRequired = true, inspect both result.isReadyToPay and result.paymentMethodPresent to determine if the consumer isReadyToPay and has a paymentMethodPresent.

Alternatively:

  • result.isButtonVisible can be used to determine whether or Google Pay™ button will be displayed.
  • existingPaymentMethodRequired is taken into account with result.isButtonVisible.
  • Also raised as event "readytopaychange".

For more information on this parameter, see button-element.

challengeRequestIndicator String Optional







Indicates the type of challenge request you wish to apply. Values:

  • NoPreference
  • NoChallenge
    • No challenge required.
  • ChallengePreferred
    • A challenge is preferred for this transaction.
  • ChallengeAsMandate
    • Must challenge this transaction.

This should not be included in the same configuration object as scaExemption.

scaExemption String Optional







To apply for an exemption from SCA, for a customer initiated transaction. Values:

  • LowValue
    • Transactions up to €45 do not require SCA, up to a maximum of five consecutive transactions, or a cumulative limit of €100.
  • TrustedBeneficiary
    • Provides the cardholder the option to add the merchant to their trusted list.
  • TransactionRiskAnalysis
    • Allows for certain remote transactions to be exempt from SCA, provided a robust risk analysis is performed.

This should not be included in the same configuration object as challengeRequestIndicator.

delayedAuthorisation Boolean Optional





For preAuths only.

Set to true to authenticate a card holder with 3D secure, without performing payment authorisation.

When set to true, the 3D Secure authentication status is returned in the response.

The payment authorisation is carried out at the stage when you are ready to collect the amount from the customer.

  • The default value = false

initialRecurringPayment Boolean Optional

Indicates if this initial payment is part of a recurring payment.


Apple Pay Request Example
Google Pay Request Example
Response Example (Judopay Receipt Object)


Once the authorisation is complete you will receive either:

  • A JSON object response (a Judopay receipt object). Example in the code snippet above.
  • An error object

The consumer should be redirected to the outcome screen and the response/error should be handled accordingly. For example, if the result = SUCCESS redirect the consumer to the Success Page, else ERROR.

For more information on the response codes, see Codes.



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 more information on error responses returned, see Web SDK Error Responses.



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: