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 Scenarios (Positive Flow)

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.

Important to Consider

• 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.

"cardAddress": {  
    "address1": "CardHolder House",  
    "address2": "1 CardHolder Street",  
    "address3": "CardHolder Area",  
    "town": "CardHolder Town",  
    "postCode": "AB1 2CD",  
    "countryCode": 826,  
    "state": "FL", 
},

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

Test Card Data

To simulate a successful registerCard request use the test card details here.

Request Parameters

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.

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: Supply: Basic {authstring} Example: Basic TXpFdPdRSzWmSGk4djhxeTpjBTS4YjQ5OTdkZmO7CTk1YTE0OWEyMDg1MmY3YWYyZWEyZTcwYmQyZGY3O     Replace {authstring} with base64 encoding of: API Token (username) Colon API Secret (password) Example: MzPdkQK1mGi8v3ky:y158n4732dfc7595a149a20381f7af2ea2e70gr6df794b8rnwc019cc5f799kk3
Authorization Method: PaymentSessionAuthToken	For Payment Session authentication In the Api-Token header: Supply the token used to authenticate the call to generate a payment session The Payment-Session header value must also be supplied.
Authorization Method: PaymentSessionAuthReference	For Payment Session authentication In the Payment-Session header: Supply the reference returned in the create payment session response The Api-Token header value must also be supplied.

 

 

Body Parameters:

Configuration Property Descriptions

 

Parameter	Description
judoId String Optional	Unique ID supplied by Judopay. Specific to a merchant and/or location. Format: 100100100 Maximum length 9 characters. Do not include spaces or dashes.
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: MM/YY
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: 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.
cardHolderName String Optional	The full name of the card holder.

 

Request Example:

Response

Response Example:

RegisterCard 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:

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

Next Steps

Using the yourConsumerReference and cardToken from the successful registerCard response, you can test the following scenarios:

• Testing Card PreAuths

• Testing Card Payments

• Testing Merchant Initiated Transactions

Related Topics

Related Topics:

• 3D Secure 2 Authentication
• Testing Card Payments
• Testing Refunds
• Testing Card PreAuths
• Testing Collections
• Testing Voids
• Testing SaveCard
• Testing CheckCard
• Testing Merchant Initiated Transactions
• Testing GET Transactions