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 conducts a zero amount pre-authorisation on the consumer's account.
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: "cardAddress": {
"address1": "CardHolder House",
"address2": "1 CardHolder Street",
"town": "CardHolder Town",
"postCode": "AB1 2CD",
"countryCode": 826,
"state": "FL",
}, 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.
To simulate a successful checkCard request use the Test Cards.
Sandbox endpoint: https://api-sandbox.judopay.com/transactions/checkcard
HTTP Method: POST
Header Parameters:
Depending on how you integrate with Judopay, you can authenticate requests by:
- /paymentsession, or
- TokenSecretAuth
- The token and secret pair
For more information, see Authentication Methods.
Body Parameters:
Configuration Property Descriptions
Declines can occur for various reasons, it can be impossible to simulate all the negative flows in a sandbox environment.
- 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. |
For a list of possible error codes, types and descriptions, see Error Codes and Descriptions.