The Directory Server connects to the card schemes, receiving the message from the MPI. The card schemes checks the card number against the BIN range directory that it holds, and forwards that message onto the correct issuing bank. The issuing bank then proceeds with authenticating the card user.

Address Verification System (AVS) is a fraud prevention scheme, using information provided by the consumer to verify the details of the card used in the transaction.

It is used to help verify details in cardholder not present transactions.

Judopay applies rate limiting at an account level, based on the merchant’s profile. This helps us to accurately detect any anomalies in usual traffic rates that may occur to protect both Judopay and you. Our team regularly reviews these to ensure our rate limits are sufficient for your requirements, but should you have any queries on this please contact Customer Support.

In online and mobile payments, security is a number one concern. Authentication and verification of the identity of the cardholder is important for preventing fraudulent transactions and refunds.

Depending on how you integrate with Judopay, the following methods are recommended to authenticate requests:

For any 3D Secure 2 requests, indicates the type of channel used to initiate the transaction. Values:

A card token is a randomly generated string linked to the saved card in Judopay’s systems. It can only be used with the associated consumer token. It can be stored in your database without worrying about PCI compliance issues.

The URL that will receive the outcome of the challenge request to the consumer. Make sure when testing MethodNotificationUrl and ChallengeNotificationUrl you use a real URL for the values. If you use a localhost URL, it will not work.

The challenge request indicator specifies the type of 3D Secure 2 challenge. Types of 3D Secure 2 Challenge Request: 

Use the /checkcard endpoint to conduct a zero amount pre-authorisation in the customer's account. This endpoint checks if the card is valid to perform a 0 Auth on a customer's account.

0 Auth means it does not hold any funds on the customer’s account. The card information is tokenised into an encrypted string and tested as part of the pre-authorisation process.

Code obfuscation is the act of making source code difficult for a human to read. Whilst it is not impossible to reverse engineer obfuscated code, the goal is to make it difficult or economically unfeasible.

Use the /collections endpoint to collect funds previously reserved using the /preauths request. You can choose to let your customer know when to expect their card to be charged.

Use the /complete3ds endpoint when authenticating with 3D Secure 2, following the 3D Secure 2 challenge being successfully completed by the consumer. 

When authenticating a 3D Secure 2 (EMV 3D Secure) card payment, Judopay collects specific device data captured via Judokit and our Android and iOS SDKs. We share these details with both the card network and issuing bank.

This is an (EMV) 3DS2 protocol requirement, enabling the card network and issuing bank to recognise repeat transactions from the same device, mitigating transaction risk.

The merchant’s Trading Name that will appear on the consumer’s statement. The value is returned in the response within the appearsOnStatement field.

The Electronic Commerce Indicator (ECI) is a value returned by Directory Servers (for example Visa, Mastercard, American Express, JCB), which represents the authentication outcome of 3D Secure 2 transactions .

Card schemes observe different liability shift rules and ECI values.

The 3D Secure liability shift is a rule protecting you from fraudulent transactions.

For example, if your consumer denies they authorised or made a purchase, (due to a lost or stolen card) and the 3D Secure authentication was successful (following either the frictionless or challenge flow), the liability for the payment shifts from you to the issuing bank.

If the 3D Secure authentication:

Liability shift does not apply to transactions where authentication is not performed.

Judopay’s sandbox environment accommodates functional testing of your integration and is not designed for load or stress testing scenarios.

Due to lower rate limits applied in sandbox, we recommend simulating test requests with a prudent level of latency applied.

Merchant Category Code 6012 is used for businesses classified as financial institutions. It is mandatory for merchants who have an MCC code of 6012 to submit additional Information about the primary account holder in the primaryAccountDetails object for payment pre-authorisation.

A parameter in the resumeThreeDSecure Model. Indicates if the 3DS ACS method to collect the device details was completed successfully.

The URL that will receive the method completion message, confirming the Issuer has completed the device details check. Make sure when testing MethodNotificationUrl and ChallengeNotificationUrl you use a real URL for the values. If you use a localhost URL, it will not work.

MOTO (Mail Order Telephone Order), allows you to take and manage card transactions remotely. This web-based payment system facilitates payment transactions that can be taken over the telephone or via email via a virtual terminal.

It is recommended to use /paymentsession to authenticate your requests. The payment session can be used for up to three transaction attempts for the same transaction. Once a transaction attempt is successful, the payment session can no longer be used even if there are any remaining attempts available.

A payment session can be used again to re-submit a failed transaction attempt.

As soon as the payment session is used for the initial transaction attempt, this will initiate the 30 minute expiry time.

Use the /preauths endpoint to reserve funds on a customer's account and postpone completing the payment until the goods have been delivered or the service fulfilled.

This is also known as reserve and collection of funds. The expiry time of the reserved pre-authorised funds differs across issuers.

Use the /refunds endpoint to return funds to the customer. You can process a full or partial refund:

Full Refund: Returns the total of the original transaction back to the customer.

Partial Refund: Returns a specified amount of the original transaction back to the customer. For example, if a customer has been overcharged, or where part of an order cannot be satisfied by the business.

The receiptId returned from the first subscription payment. Adding the relatedReceiptId references the subsequent recurring transactions to the original transaction.

Use the /resume3ds endpoint when authenticating with 3D Secure 2, following the 3D Secure 2 device details being successfully completed by the consumer.

Use the /savecardendpoint If you do not want to perform a pre-authorisation check on a customer's account. Use this call to tokenise the card information into an encrypted string. The Card Token is not tested until it is used. 

A soft decline can be caused by many factors, and is usually influenced by the issuer's risk assessment logic. However, it mostly occurs when the issuer indicates Strong Customer Authentication (SCA) must take place before the transaction request can be authorised.

Step-up authentication will automatically re-submit soft declined transactions to Judopay’s Transaction API, after re-authenticating the cardholder with a mandated challenge.

Use the /voids endpoint to cancel a pre-authorised transaction if the funds have not yet settled. Not all banks support voiding transactions. Check with your Acquirer. Voids cannot be performed on transactions that have been collected (partial or full).

Webhooks are an optional secure service provided by Judopay to use to notify your system when a transaction or event has taken place.

The benefit of using webhooks means you do not need to pull information from the Judopay API for every event.

A unique reference to anonymously identify your consumer.

A unique reference to identify a transaction. 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.