Testing your Integration
...
Testing Overview
Testing your Mobile SDK Integr...

Testing Android SDK - Card Payments

Testing Android SDK - Card Payments

With Judopay’s Android Mobile SDK solution, a minimal integration is all that is required to enable you to:

  • Take a card payment
  • Take a card preAuth
  • Take a card token payment
  • Take a card token preAuth
  • Check the validity of a card, using checkCard
  • Save the card details, using saveCard


Card Payment Scenarios (Positive Flow)

Depending on your use case and app configurations, some of the following scenarios may not be relevant to you.

Follow our suggested guidelines to simulate positive / happy path scenarios, in the sandbox environment, using the Test Cards to test your integration is working correctly.

This will give you confidence for when your integration goes live.

*These images are from our dummy app, your interface may look different.





Suggested Test Scenario

Process a card:

  • payment
  • preAuth

Use the test card details here.



TIP: The app is using the payment / preAuth flow, which has been set up in the payment configuration object.

Expected Outcome

You will be directed to a successful transaction completed page. *

successful page



Suggested Test Scenario

Process a card :

  • token payment
  • token preAuth


TIP: The app is using the token payment / token preAuth flow, which has been set up in the payment configuration object.

If your app allows the consumer to save their card details, use the save card scenario and use the saved card token reference to make a payment.

Expected Outcome

You will be directed to a successful transaction completed page. *

successful page



Suggested Test Scenario

Process a card payment prompting the consumer to enter their billing address.

Expected Outcome

Depending on your use case and app configuration:

  • The Android SDK prompts the consumer to enter their billing details.



Example Flow: Prompting the consumer to enter their billing address: *

prompt enter billing address



Suggested Test Scenario

Process a card payment without the billing address fields displayed.

Expected Outcome

Depending on your use case and app configuration:

  • The Android SDK does not prompt the consumer to enter their billing details.

If you process a token payment, the billing details form will not be displayed in the payment flow. This is due to the card token being used, which already has the cardholders details securely saved.



Example 'No Challenge' Flow: *

android no challenge flow



Suggested Test Scenario

Handle a 3D Secure 2 flow.



TIP: 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. For more information on the 3DS 2 flow, see Overview of the Frictionless and Challenge Flow.

Expected Outcome

Depending on your use case and app configuration:

  • Use the Card Holder Name table to trigger any 3D Secure 2 flow, see CardHolderName Table.
  • Your app explicitly forces a challenge flow, so the consumer will be directed to the challenge page.

For the purpose of this exercise, below we have an example of a:

  • Frictionless flow.
  • Successful challenge flow.
  • Unsuccessful challenge flow.



Example 3D Secure 2 'Frictionless' Flow: *

android no challenge flow



Example Successful 3D Secure 2 'Challenge' Flow: *

Android successful challenge flow



Example Unsuccessful 3D Secure 2 'Challenge' Flow: *

android payment failed



Test Card Data

To simulate a successful card payments request, use the Test Cards.



Calling the Mobile SDK Functions

For more information on integrating your Android app, including calling the Mobile SDK functions see Integrating with Judopay.



Card Payment Scenarios (Negative Flow)

Declines can occur for various reasons, it can be impossible to simulate all the negative flows in a sandbox environment. Depending on your use case and app configurations, some of the following scenarios may not be relevant to you.

Follow our suggested guidelines to simulate negative scenarios, to test your app’s error handling. This will give you confidence for when your integration goes live.

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

*These images are from our dummy app, your interface may look different.



Suggested Negative Test Scenario

To handle a decline scenario, attempt to perform a card:

  • payment
  • preAuth

request decline using the following:

  • cardNumber: 4221690000004963
  • cv2: 452
  • expiryDate: 12/24

Expected Error and Description

Card declined

You will be re-directed to an error page with an error message. *

payment failed screen



Suggested Negative Test Scenario

To handle a decline scenario, attempt to perform a card:

  • payment
  • preAuth request decline.

Using the following example use cases:

  • Enter an invalid cvv
  • User taps the cancel button on the 3DS 2 challenge screen

Expected Error and Description

Card declined

You will be re-directed to an error page with an error message. *

payment failed screen



Suggested Negative Test Scenario

Attempt to perform a card payment where the incorrect card details are entered.

This will perform the field validation checks.

Expected Error and Description

Payment declined

Form validation error messages will be displayed in the form.

The Pay Now button will be greyed out. *

android greyed out button