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

Testing Merchant Initiated Transactions

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.

Merchant Initiated Transactions (MIT) Scenarios (Positive Flow)

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.



Important to Consider

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

Batch Based MIT Tests

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:

  • relatedReceiptId : {{receiptId}}
  • recurringPayment : true
  • recurringPaymentType : MIT

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:

  • relatedReceiptId : {{receiptId}}
  • recurringPayment : true
  • recurringPaymentType : MIT

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:

  • relatedReceiptId : {{receiptId}}
  • recurringPayment : true
  • recurringPaymentType : MIT

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:

  • relatedReceiptId : {{receiptId}}
  • recurringPayment : true
  • recurringPaymentType : MIT

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" }


Test Card Data

To simulate a successful MIT payment use the Test Cards.



MIT Request Parameters

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:

  • 100100100
  • Maximum length 9 characters.
  • Do not include spaces or dashes.

amount Decimal Required

The amount to process. Format:

  • Two decimal places

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:

  • GBP
  • USD
  • EUR

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:

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

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:

  • RECURRING (for scheduled payments) or
  • MIT (for unscheduled payments).

relatedReceiptId String Optional

The receiptId returned from the first subscription payment.

Adding the relatedReceiptId references the subsequent recurring transactions to the original transaction.

MIT Request Example
Response Example



Merchant Initiated Transactions (MIT) 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:

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.