Testing SaveCard

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.

 

SaveCard Scenarios (Positive Flow)

Use saveCard If you do not want to perform a pre-authorisation check on a customer's account. SaveCard stores the card details and tokenises the card number into an encrypted string.

 

During the saveCard request flow, Judopay validates the fields in the request model before storing the card details and tokenising the card number.
If the request fails these checks, for example due to an incorrect field value, or the field has been incorrectly formatted, you will receive a model error response.. For more information, see Model Errors

The cardToken is not validated by the issuer, until it is used in a payment or preAuth request.

 

Important to Consider

  • SaveCard involves storing the card details:

    • cardNumber

    • cardExpiryDate

    • cv2

  • Tokenises the card number into an encrypted string.

  • The saveCard request is not processed through the 3D Secure 2 flow and is not authenticated.

  • You cannot use the receiptId from the saveCard response for Merchant Initiated Transactions.

    • This is due to the saveCard request not being validated by the issuer.

      For more information on the Merchant Initiated Transaction flow, see Important to Consider - MIT Flow.

SaveCard does not validate the card or account, as the request does not go to the payment gateway.

Suggested Field Validation Test Scenario

 Expected Outcome Tip

Process a saveCard request with the CV2/CVV security code included in the request to check the CV2/CVV field format is valid.

200

Successful

The CV2 field validation check will be performed during the process.

Process a saveCard request without the CV2/CVV security code included in the request.

 

Declined

The CV2 field validation check will not be performed during the process.

 

Process a saveCard request with the billing address information (cardAddress block) included in the request to check the fields are correct.

200

Successful

Ensure the cardAddress block has the correct fields:

  • address1

  • address2

  • address3

  • town

  • postCode

    • Required

  • countryCode

    • Any ISO 3166-1 3 digit country code of the card holder's address.

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:

  • Enforce AVS checks.

The default setting = disabled.

Process a saveCard request without the billing address information (cardAddress block) included in the request.

200

Successful

 

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

 

Test Card Data

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

 

Request Parameters

Sandbox endpoint: https://api-sandbox.judopay.com/transactions/savecard

HTTP Method: POST

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:

 

 

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.

 

cardHolderName

String

Optional

The full name of the card holder.

 

 

Request Example:

 

Response

Response Example:

 

SaveCard Scenarios (Negative Flow)

Field and formatting errors can occur for various reasons, it can be impossible to simulate all the model errors 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 model errors, to test your app’s error handling:

Suggested Field Validation Negative Scenario

Expected Error Code

 Model Error Description
Attempt to perform a saveCard request using an invalid/expired card expiry date.

46

 

 
{
    "details": [
        {
            "code": 46,
            "fieldName": "ExpiryDate",
            "message": "Sorry, but the expiry date entered is in the past. 
             Please check your details and try again."
        }

 

Attempt to perform a saveCard request using an invalid card number.

For example use 13 digits for the card number.

 30 
{
    "details": [
        {
            "code": 30,
            "fieldName": "CardNumber",
            "message": "Sorry, it looks like the card number entered is invalid. 
             Please check your details and try again."
        }

 

Attempt to perform a saveCard request with an invalid CV2 field format.

 

For example "ABC123".

1

 
{
    "details": [
        {
           "message": "Sorry, we're unable to process your request. 
            Please check your details and try again.",
           "code": 1,
           "category": 2
}

 

Attempt to perform a saveCard request with a missing CV2.

The sandbox token has cv2 enabled, the saveCard request has an empty cv2 field.

 31 
{
    "details": [
        {
            "code": 31,
            "fieldName": "Cv2",
            "message": "Sorry, you've not supplied the 3-digit card security code. 
             Please check your details and try again."
        }

 

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 cardToken from the saveCard response, you can test the following scenarios:

 

Related Topics

Related Topics Link IconRelated Topics: