Testing RegisterCard
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.
RegisterCard conducts a pre-authorisation by reserving a pre-configured amount in the customer's account.
The pre-configured amount is set during your on-boarding process (the default amount is 1.01).
RegisterCard will tokenise the card information into an encrypted string, which can be used for future transactions.
The POST /transactions/voids endpoint can be used to cancel this pre-authorisation so it does not appear in the customer's statement.
- RegisterCard 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.
- Store yourConsumerReference and cardToken and supply these in future card payment, preAuth, or Merchant Initiated Transaction requests.
A successful registerCard 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 registerCard request with the CV2/CVV security code included in the request. This will check the CV2/CVV is valid for that card. | 200 Successful | The CV2 field check will be performed during the transaction process. |
Process a registerCard request without the CV2/CVV security code included in the request. | Declined | The CV2 field check will not be performed during the transaction process. |
Process a registerCard 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",
"address3": "CardHolder Area",
"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. |
Process a registerCard request without the billing address information (cardAddress block) included in the request. | 200 Successful | |
For more information on API credentials and permissions, see Permissions.
To simulate a successful registerCard request use the Test Cards.
Sandbox endpoint: https://api-sandbox.judopay.com/transactions/registercard
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
Parameter | Description |
|---|---|
judoId String Optional | Unique ID supplied by Judopay. Specific to a merchant and/or location. Format:
|
cardNumber String Required | The unique number printed on the card (13 to 19 digits depending on card type). Submitted without whitespace or non-numeric characters. |
expiryDate String Required | The expiry date of the card. Format:
|
cv2 String Optional | The 3 or 4 digit number on the back of the card. Also known as the card verification value (CVV) or security code. |
yourConsumerReference String Required | Unique reference to anonymously identify your customer. Advisable to use GUIDs. Must be below 40 characters. |
yourPaymentReference String Optional | 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. |
cardHolderName String Optional | The full name of the card holder. |
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 registerCard request using an invalid card expiry date. | 161 | Sorry, but the card expiry date must be in the future. |
Attempt to perform a registerCard request using an invalid card number. | 196 | Unable to process transaction as the card number is invalid. Please try again with a different card. |
Attempt to perform a registerCard request with an invalid CV2. | 74 | The CV2 entered is invalid. |
Attempt to perform a registerCard request with a missing CV2. The sandbox token has cv2 enabled, the registerCard request has an empty cv2 field. | | Sorry, you've not supplied the 3-digit card security code. Please check your details and try again. This is a model error. |
Simulate a decline using the following test card details: | | |
Attempt to perform a registerCard decline using the following:
| Declined
| Card declined. |
For a list of possible error codes, types and descriptions, see Error Codes and Descriptions.
Using the yourConsumerReference and cardToken from the successful registerCard response, you can test the following scenarios: