Testing your Integration
...
Testing Overview
Testing your Direct (API) Inte...

Testing Card Payments

Testing Card Payments

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.

Card Payment and Card Token Scenarios (Positive Flow)

Important to Consider

  • yourPaymentReference is your unique reference for each transaction.
  • When making token payments, yourConsumerReference must match the original reference when the token was initially created.

Suggested Test Scenario

Expected Outcome

Tip

Process a card payment 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 card payment 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 card token payment with the CV2/CVV security code included in the request. This will check the CV2/CVV and card token are valid and match the stored card details.

200 Successful

The CV2 field check will be performed during the transaction process. When making token payments, yourConsumerReference must match the original reference when the token was initially created.

Process a card token payment without the CV2/CVV security code included in the request.

200 Successful

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

When making token payments, yourConsumerReference must match the original reference when the token was initially created.

Process a card payment with the billing address information (cardAddress block) included in the request. This will validate the billing address is registered to that card.

200 Successful

When making token payments, yourConsumerReference must match the original reference when the token was initially created.

Ensure the cardAddress block has the correct fields:

  • address1
  • address2
  • town
  • postCode
    • Required
  • countryCode
    • See here for the list of valid ISO 3166-1 format country codes.

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:

  • Enforce AVS checks.

The default setting = disabled.

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

200 Successful



Process a card token payment with the billing address information (cardAddress block) included in the request. This will validate the billing address and card token are valid and match the stored card details.

200 Successful

Ensure the cardAddress block has the correct fields:

  • address1
  • address2
  • town
  • postCode
    • Required
  • countryCode
    • See here for the list of valid ISO 3166-1 format country codes.

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:

  • Enforce AVS checks.

The default setting = disabled.

When making token payments, yourConsumerReference must match the original reference when the token was initially created.

Process a card token payment without the billing address information (cardAddress block) included in the request.

200 Successful

When making token payments, yourConsumerReference must match the original reference when the token was initially created.

Process a card payment using the different currencies you will be implementing on your app.

200 Successful

If you do not provide a currency in the payment request, the default value (GBP) will be sent.

Ensure you have the correct currencies configured for your app.

Process a card payment for MCC 6012 merchants, with the primaryAccountDetails block included in the request.

It is mandatory for merchants who have an MCC code of 6012 to submit additional Information about the primary account holder for payment pre-authorisation.

For use by MCC 6012 merchants only.

200 Successful

Ensure you send the primaryAccountDetails block in your request:

  • name This is the surname.
  • accountNumber
  • dateOfBirth
    • Format: YYYY-MM-DD
  • postCode

Example primaryAccountDetails block:

"primaryAccountDetails": { "name": "Smith", "accountNumber": "1234567890", "dateOfBirth": "1980-01-01", "postCode": "AB1 2CD" }

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



Test Card Data

To simulate a successful payment use the Test Cards.



Card Payment and Card Token Request Parameters

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

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





Card Payment Request Body Example
Card Token Request Body Example
Response Example


If your request was successful, you will receive a code 200 and a receiptId. A receiptId is Judopay's unique reference for the transaction. It is used to process refunds or cancellations and to help us investigate any issues with the transaction.



Card Payment 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

To simulate an unsuccessful flow, use the following test card details:

Card Type

Card Name

Card Number

Expiry Date

Start Date

CV2

Address

Visa

Ian Lee

4221690000004963

12/22

01/18

125

274 Grove Street, Rayvale, Vertland VT22 6JN

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 a payment with an invalid CV2

74

The CV2 entered is invalid.

Attempt a payment with a missing CV2.

The sandbox token has CV2 enabled, the payment request has an empty CV2 field.

31

Sorry, you've not supplied the 3-digit card security code. Please check your details and try again.

This is a model error.

Attempt a payment with insufficient funds in the account.

Declined.

Card declined.

Simulate an error resulting from invalid data:





Attempt a payment with an incorrect card number entered.

166

Unable to process transaction. No record of card number found by 3DS Server.

Attempt a payment with an invalid card expiry month = 14

161

Sorry, but the card expiry date must be in the future.

Attempt a payment using the Incorrect card token.

70

Sorry, but it looks like the card token specified is not valid.

Please check your details and try again.

Simulate an error resulting from incorrect API credentials:





Attempt a payment using the Incorrect judoId.

77

Judo id not found, please check the judo id.

Attempt a payment with the Incorrect currency entered for the specified transaction.

72

Sorry, we're currently unable to route this transaction. Please check your account details and try again.

If this issue persists, please contact customer services.

This is a processing error.



For a list of possible error codes, types and descriptions, see Error Codes and Descriptions.



Next Steps

Using the successful payment test transactions, you can test the following scenarios. Making a: