Payments Glossary

payments glossary 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 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 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 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