Testing Merchant Initiated Transactions
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.
The first subscription payment must have followed the 3D Secure 2 flow. Contact Developer Support if you have any queries on initial MIT payments.
See MITs for more information.
- Provide the following fields and associated values in your MIT requests:
- recurringPayment
- Indicates if this is a recurring payment.
- relatedReceiptId
- The receiptId returned from the first subscription payment.
- Must be as a result of the initial transaction being processed through a 3D Secure 2 flow.
- recurringPaymentType
- Indicates the type of recurring payment.
- This can be set to 'RECURRING' (for scheduled payments) or 'MIT' (for unscheduled payments).
- Store the cardToken and relatedReceiptId, as they will be required for future transactions.
- The relatedReceiptId must be as a result of an initial transaction processed from a 3D Secure 2 flow.
- You need to tag your MIT / recurring transactions correctly using the relatedReceiptId. This is to ensure your transactions are not declined by your customers’ issuing bank.
- The relatedReceiptId is the receiptId returned from the first subscription payment. It references all subsequent recurring transactions to the original transaction.
Following testing MIT transactions in the sandbox environment, it is critical these are tested again with live transaction tests prior to formally going live, as sandbox behaviour differs slightly to live.
Due to rate limits applied in both sandbox and production, we recommend adding pauses between each MIT batch transaction. Otherwise the quota limit may block transactions and cause undesirable results.
Suggested Test Scenario | Expected Outcome | Tip |
---|---|---|
Perform a Card Token Payment. This will check the card token is valid and matches the stored card details. | 200 Successful | Ensure you have provided the following fields:
Example Schema: {
"cardToken": "Va8hCyhAPcNeKJLMQcymfFdLU7njkZ9A",
"judoId": 100100100,
"yourConsumerReference": "2b45fd3f-cee5-4e7e-874f-28051db65408",
"yourPaymentReference": "6482c678-cad3-4efd-b081-aeae7a89a134",
"currency": "GBP",
"amount": 1.01,
"recurringPayment": true,
"recurringPaymentType": "MIT",
"relatedReceiptId": "689469972283396100"
} When making token payments, yourConsumerReference must match the original reference when the token was initially created. |
Perform a Card PAN Payment. | 200 Successful | Ensure you have provided the following fields:
Example Schema: {
"cardNumber": "4111111111111111",
"judoId": 100100100,
"yourConsumerReference": "2b45fd3f-cee5-4e7e-874f-28051db65408",
"yourPaymentReference": "6482c678-cad3-4efd-b081-aeae7a89a134",
"currency": "GBP",
"amount": 1.01,
"recurringPayment": true,
"recurringPaymentType": "MIT",
"relatedReceiptId": "689469972283396100"
} |
Perform a Card Token preAuth. This will check the card token is valid and matches the stored card details. | 200 Successful | Ensure you have provided the following fields:
Example Schema: {
"cardNumber": "4111111111111111",
"judoId": 100100100,
"yourConsumerReference": "2b45fd3f-cee5-4e7e-874f-28051db65408",
"yourPaymentReference": "6482c678-cad3-4efd-b081-aeae7a89a134",
"currency": "GBP",
"amount": 1.01,
"recurringPayment": true,
"recurringPaymentType": "MIT",
"relatedReceiptId": "689469972283396100"
} When making token preAuths, yourConsumerReference must match the original reference when the token was initially created. |
Perform a Card PAN preAuth. | 200 Successful | Ensure you have provided the following fields:
Example Schema: {
"cardToken": "Va8hCyhAPcNeKJLMQcymfFdLU7njkZ9A",
"judoId": 100100100,
"yourConsumerReference": "2b45fd3f-cee5-4e7e-874f-28051db65408",
"yourPaymentReference": "6482c678-cad3-4efd-b081-aeae7a89a134",
"currency": "GBP",
"amount": 1.01,
"recurringPayment": true,
"recurringPaymentType": "MIT",
"relatedReceiptId": "689469972283396100"
} |
To simulate a successful MIT payment use the Test Cards.
Sandbox endpoint: https://api-sandbox.judopay.com/transactions/payments Sandbox endpoint: https://api-sandbox.judopay.com/transactions/preauths
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 |
---|---|
cardToken String Required | A randomly generated string linked to a card saved securely within the Judopay Card Vault. |
judoId String Required | Unique ID supplied by Judopay. Specific to a merchant and/or location. Format:
|
amount Decimal Required | The amount to process. Format:
For currencies using a different structure please contact Judopay for support. |
currency String Required | The currency of the transaction. Any ISO 4217 alphabetic currency code:
|
yourConsumerReference String Required | Unique reference to anonymously identify your customer. Advisable to use GUIDs. Must be below 40 characters. |
yourPaymentReference String Required | 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. |
recurringPayment String Optional | Indicates if this is a recurring payment. |
recurringPaymentType String Optional | Indicates the type of recurring payment that the merchant is attempting to process. This can be set to:
|
relatedReceiptId String Optional | The receiptId returned from the first subscription payment. Adding the relatedReceiptId references the subsequent recurring transactions to the original transaction. |
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 a payment with an invalid relatedReceiptId. | 20026
| The receipt ID specified is not valid for the request you are attempting. |
Attempt a payment where the relatedReceiptId for the original transaction, did not follow the 3D Secure 2 flow. | 185 | Authentication rejected by the Issuer as card authentication has failed. |
Attempt a payment with an incorrect yourConsumerReference. | 154 | Your provided consumer reference is incorrect, please check your details and try again. |
For a list of possible error codes, types and descriptions, see Error Codes and Descriptions.