--- title: Payments Glossary slug: payments-glossary docTags: createdAt: 2024-07-04T16:57:31.982Z --- ## 3D Secure Directory Server 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 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. *** ## API Rate Limits 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. *** Authentication Methods ---------------------- 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: - Using our SDKs: - `/paymentsession` - Calling directly to our Transaction API: - `/paymentsession`, or - TokenSecretAuth - The token and secret pair *** ## authenticationSource For any 3D Secure 2 requests, indicates the type of channel used to initiate the transaction. Values: - Unknown - Browser - Merchant\_Initiated - Mobile\_Sdk  *** ## Card Token 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. *** ## challengeNotificationUrl 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. *** ## Challenge Request Indicator The challenge request indicator specifies the **type **of 3D Secure 2 challenge. Types of 3D Secure 2 Challenge Request:  - No Preference - No Challenge - Challenge Preferred - Challenge As Mandate *** Check Card ---------- 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 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. *** Collections ----------- 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. *** complete3ds ----------- Use the `/complete3ds` endpoint when authenticating with 3D Secure 2, following the 3D Secure 2 challenge being successfully completed by the consumer.  *** ## Device Data Collection 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. *** ## Dynamic Descriptor The merchant’s **Trading Name** that will appear on the consumer’s statement. The value is returned in the response within the **appearsOnStatement** field. *** ## Electronic Commerce Indicator (ECI) 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. *** ## FBI (Financial Beneficiary Identification) Merchants The merchants with the following Merchant Category Codes are flagged as FBI merchants because **funds sent to them are considered "beneficiary" transactions** - **not payment for goods/services**, but moving money between accounts. It is **mandatory **for merchants who have an MCC code of **6012**, **6051 **and **7299 **to submit **additional Information **about the primary account holder in the `primaryAccountDetails` object for payment pre-authorisation. - **6012** - Financial Institutions - Merchandise and Services - **6051** - Quasi Cash (crypto, prepaid loads) - **7299** - Misc. Personal Services (often used for money transfer, crypto, or investment platforms in some contexts) *** ## Liability Shift 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: - was attempted but not successful - could not be performed - failed the liability **does not shift** and remains with you. Liability shift does not apply to transactions where authentication is not performed. *** Load and Functional Testing --------------------------- 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. *** ## MCC 6012 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. *** ## MCC 6051 Merchant Category Code 6051 is used for businesses classified as Quasi Cash (crypto, prepaid loads). It is **mandatory **for merchants who have an MCC code of 6051 to submit **additional Information **about the primary account holder in the `primaryAccountDetails` object for payment pre-authorisation. *** ## MCC 7299 Merchant Category Code 7299 is used for businesses classified as Misc. Personal Services (often used for money transfer, crypto, or investment platforms in some contexts). It is **mandatory **for merchants who have an MCC code of 7299 to submit **additional Information **about the primary account holder in the `primaryAccountDetails` object for payment pre-authorisation. *** ## methodCompletion A parameter in the **resumeThreeDSecure** Model. Indicates if the 3DS ACS method to collect the device details was completed successfully. *** ## methodNotificationUrl 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 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. *** ## Payment Session 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. :::hint{type="info"} The paymentSession will expire in 30 minutes, unless an ExpiryDate is set in the `/paymentsession` request body. ::: As soon as the payment session is used for the initial transaction attempt, this will initiate the 30 minute expiry time. *** ## Preauths 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. *** ## Refunds 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. *** relatedReceiptId ---------------- The **receiptId **returned from the **first **subscription payment. Adding the `relatedReceiptId` references the subsequent recurring transactions to the original transaction. *** ## resume3ds Use the `/resume3ds` endpoint when authenticating with 3D Secure 2, following the 3D Secure 2 device details being successfully completed by the consumer. *** Save Card --------- Use the `/savecard`endpoint 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.  *** ## Soft Decline 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**. *** ## Voids 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 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. *** ## yourConsumerReference A unique reference to anonymously identify your consumer. *** ## yourPaymentReference 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. ***