Testing CheckCard
These scenarios do not include 3D Secure 2 authentication testing.
See Testing 3D Secure 2 Flows for 3D Secure 2 authentication testing for your app.
CheckCard Scenarios (Positive Flow)
CheckCard conducts a zero amount pre-authorisation on the consumer's account.
Important to Consider
Zero Auth means it does not hold any funds on the customer’s account.
-
CheckCard tests involve verification of:
-
The card:
-
cardNumber
-
cardExpiryDate
-
cv2
-
-
The account:
-
Is not blocked or blacklisted
-
Exists
-
-
-
Tokenises the card number into an encrypted string.
A successful checkCard request verifies the card with the issuer and can be authenticated using 3D Secure 2. Providing you with the confidence the card is valid to make future payments.
Suggested Test Scenario |
Expected Outcome | Tip |
---|---|---|
Process a Card Payment. This will check the card is valid. |
200 Successful |
The checkCard response provides the:
Ensure you use the correct cardToken and yourConsumerReference to make future payments, otherwise they may fail. |
Process a Card preAuth. This will check the card is valid. |
200 Successful |
The checkCard response provides the:
Ensure you use the correct cardToken and yourConsumerReference to make future payments, otherwise they may fail. |
Process a checkCard request using the different card schemes you will be implementing on your app. |
200 Successful |
Ensure you have the correct card schemes enabled on your app. |
Process a checkCard request with the billing address information (cardAddress block) included in the request.
This will validate the billing address is registered to that card. |
200 Successful |
Ensure the cardAddress block has the correct fields:
Example cardAddress block:
To validate the card is registered to the correct post code, ensure the following permission on your sandbox API Credentials is enabled:
The default setting = disabled. |
For more information on API credentials and permissions, see Permissions.
Test Card Data
To simulate a successful checkCard request use the test card details here.
Request:
Sandbox endpoint: https://api-sandbox.judopay.com/transactions/checkcard
HTTP Method: POST

API-Version: |
6.20
For the latest version of the Judopay Transaction API, see Latest Version. |
|||
Content-Type: |
application/json |
|||
Accept: |
application/json |
|||
Authorization Method TokenSecretAuth |
In the Authorization Header:
Example: Basic
Replace {
Example: MzPdkQK1mGi8v3ky:y158n4732dfc7595a149a20381f7af2ea2e70gr6df794b8rnwc019cc5f799kk3 |
|||
Authorization Method: PaymentSessionAuthToken |
For Payment Session authentication In the Api-Token header:
The Payment-Session header value must also be supplied. |
|||
Authorization Method: PaymentSessionAuthReference |
For Payment Session authentication In the Payment-Session header:
The Api-Token header value must also be supplied. |
Body Parameters:

Parameter |
Description |
---|---|
judoId String Required |
Unique ID supplied by Judopay. Specific to a merchant and/or location. Format:
|
amount Decimal Required |
The amount to process. Format:
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:
|
phoneCountryCode String Optional |
The country code of the consumer's phone. Format:
|
challengeRequestIndicator String Optional |
Indicates the type of challenge request you wish to apply. Values:
|
scaExemption String Optional |
To apply for an exemption from SCA, for a customer initiated transaction. Values:
|
initialRecurringPayment Boolean Optional |
Indicates if this initial payment is part of a recurring payment. |
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:
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. |
billingAddress Object Optional |
Card holder's billing address.
If the billingAddress is provided, the postcode is required. |
mobileNumber String Optional |
Consumer’s valid mobile number. Format:
|
emailAddress String Optional |
Consumer’s valid email address. It is recommended but not required for 3D Secure 2 authentication. |
primaryAccountDetails Object Optional |
This is Mandatory for merchants who have an MCC code of 6012 Primary Account Holder Details:
This is the surname.
|
Request Example:
Response
Response Example:
CheckCard Scenarios (Negative Flow)
Declines can occur for various reasons, it can be impossible to simulate all the negative flows in a 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
Follow our suggested guidelines to simulate negative scenarios, to test your app’s error handling:
Suggested Negative Test Scenario |
Expected Error Code |
Error Description |
---|---|---|
Attempt to perform a checkCard using an invalid card expiry date. |
161 |
Sorry, but the card expiry date must be in the future. |
Attempt to perform a checkCard using an invalid card number. | 196 | Unable to process transaction as the card number is invalid. Please try again with a different card. |
Simulate a decline using the following test card details: | ||
Attempt to perform a checkCard decline using the following:
|
Declined | Card declined. |
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
Related Topics