Glossary

An Administration Advice Message from the Acquirer. For more information, see the External Host Interface (EHI) Guide.

3D Secure (3-domain structure), also known as a payer authentication, is a security protocol that helps to prevent fraud in online credit and debit card transactions. This security feature is supported by Visa and Mastercard and is branded as ‘Verified by Visa’ and ‘Mastercard SecureCode’ respectively.

For more information, see the 3D Secure Guide.

Figure 1-2: 3D Secure Transaction Flow

A system used to manage the 3D Secure authentication service for the issuer. During an authentication session, the ACS communicates with the Card Scheme and Thredd systems, and may also interact with the cardholder, by providing Challenge screens. For more information, see the Web Services Guide.

Pass code or activation code which you supply to Thredd . You can use the access code to authenticate user access to card services or to request a user to activate the card by entering their access code. For more information, see the 3D Secure Guide (Apata).

A standard message type which allows the merchant to check the Card Validation Code (CVC) and, if address details are provided, to optionally use the Address Verification Service (AVS). If these checks are successful Thredd responds with an 00 approval to the merchant. They normally then submit a second transaction, but with an actual transaction amount included. For more information, see the External Host Interface (EHI) Guide. For more information on application of card fees for ASI transaction declines, see the Fees Guide.

A type of authorisation transaction which is intended to confirm that the account is genuine and active. Account Verifications are always for a zero amount, so only appear in Authorisation messages and never in clearing messages. For more information, see the External Host Interface (EHI) Guide and Transaction XML Guide.

The merchant acquirer or bank that offers the merchant a trading account, to enable the merchant to take payments in store or online from cardholders.
For more information about the role of the acquirer in card payment processing, see the Key Concepts Guide.

Activation Code Network Message. The message sent to Thredd and also the Program manager via EHI which contains the One Time Password (OTP) to verify the cardholder. For more information, see the Tokenisation Service Guide.

An AVS check compares the billing address used in the transaction with the issuing bank’s address information on file for that cardholder. Depending on whether they match fully, partially, or not at all, the merchant can use that information in their decision on whether or not to accept or cancel the order. AVS is one of the most widely used fraud prevention tools in card-not-present transactions. For more information, see Managing Risk.

Apata provide an Access Control Server (ACS) that enables support for the 3D Secure cardholder authentication scheme. See: https://apata.com/

Cryptogram created when a transaction is declined, helping issuers validate their risk management processes. See also: Application Cryptogram.

The Application Cryptogram is an encrypted value generated by the EMV chip card during a transaction. It is used for transaction validation, fraud prevention and data security. here are several types of application cryptograms used in EMV transactions: ARQC, ARPC and AAC.

Process of managing disputes raised between merchants and cardholders, where the dispute cannot be resolved. The arbitration process is managed by the card scheme, who will make the final decision. For more information, see the Payments Dispute Management Guide.

Controls the dates and times when authorisations on a card are allowed. You can use this option to control when the card can be used, for example, to prevent usage on weekends or out of hours. For more information, see the Web Services Guide.

Authentication can refer to the following:

• 3D Secure Authentication message sent from the Merchant to the 3-D Secure service provider to obtain cardholder authentication before submitting an Authorisation message via the Acquirer to Visa/Mastercard.
• Card authentication checks that may be carried out at Visa/Mastercard, Thredd (and occasionally the Program Manager on receipt of EHI message) to validate that the card is genuine.
• Cardholder authentication checks that may be carried out at Visa/Mastercard, Thredd (and occasionally the customer on receipt of EHI message) to validate that the cardholder is genuine.

For more information, see the Key Concepts Guide.

This refers to the process where the merchant/acquirer requests Authorisation for a card transaction. This can include any of:

• Requesting authorisation from the chip card.
• Requesting authorisation from the Issuer (or a stand-in system on behalf of the Issuer if they are not available), by sending an Authorisation Request message to Visa/Mastercard; see 0100 Message.
• Authorising the transaction locally, either at the merchant terminal or at the Acquirer. Visa/Mastercard rules will dictate when this is permitted and who would be liable if the transaction was fraudulent.

Cryptogram generated by the card when a transaction is initiated and sent to the issuer for authorization. It validates that the transaction details match what is expected and confirms that the card is legitimate. See also: Application Cryptogram.

Cryptogram generated by the issuer in response to an ARQC. It indicates whether the transaction has been approved or declined and provides additional verification. See also: Application Cryptogram.

An authorisation reversal occurs when a merchant wants to reverse a previously submitted authorisation request (e.g., because the authorised amount was entered incorrectly or the customer cancelled the order). The authorisation reversal normally occurs very soon after the original authorisation and can be matched to the original authorisation using the traceid_lifecycle. For more information, see the External Host Interface (EHI) Guide.

Automated Back Office is a service for Card Issuers, BaaS providers and BIN Sponsor, which automates the manual processes for running a compliant card programme.

The automated back office platform offers reliable data on the transaction lifecycle, reduces compliance and reconciliation issues, and helps you automate and modernise your backend programme management functions so you can focus on building innovative products for the payment’s ecosystem. For more information, see the Automated Back office Guide.

Automatic Fuel Dispensers are machines that can be used to deliver fuel to vehicles, normally at a petrol station. These are identified with a specific Merchant Category Code of 5542. The cardholder pays at the machine, normally by inserting their card (or swiping or contactless), and the fuel pump machine will then either:

• authorise a maximum amount (e.g., £100), then pump up to this, and send an advice to say how much fuel was actually delivered (common outside USA).
-or-
• authorise a nominal amount (e.g., 1 USD), then pump up to the permitted maximum it is allowed to clear according to the chargeback rules, then it will send an advice to say how much fuel was actually delivered (common in USA).

For more information, see the External Host Interface (EHI) Guide.

The Bank Identification Number (BIN) is the first six to eleven numbers on a payment card, which identifies the institution that issues the card. For more information, see the Key Concepts Guide.

Figure 1-3: Example of a card BIN

Bankers Automated Clearing System (BACS) is an electronic system for making payments directly from one bank account to another, such as bank-to-bank transfers. BACS payment services are operated and managed by BACS Payment Schemes Limited, a membership organisation consisting of 16 of the UK's leading banks. For more information, see the Key Concepts Guide.

Issuer, who creates the BIN range used by the Program Manager. For more information, see the Key Concepts Guide.
See also Pros and Cons of using a shared BIN vs. your own BIN.

Biometrics are body measurements and calculations related to human characteristics that are unique to each person (such as face, eyes, voice and fingerprints). Biometrics authentication is used as a form of identification and access control.

The Linkage Group set up on the Thredd Platform controls various parameters related to linked cards; for details, check with your Implementation Manager. For more information, see the Key Concepts Guide.

Thredd has relationships with existing card manufacturers, who we can instruct to print your cards. We use Secure FTP (sFTP) to send the card manufacturer a generated bulk XML file containing card details. This is sent on a daily basis, or at a frequency that can be customised for your service. The card manufacturer prints the cards and sends to the cardholder. Any white label test cards are typically sent to Thredd , the Program Manager and the Card Schemes.
For a list of supported card manufacturers, see the Web Services Guide.
For Thredd card interface specifications to be used by manufacturers, see the Card Generation Interface Specification.

Card on File (COF) token request created by an online merchant. For more information, see the Tokenisation Service Guide.

Card network, such as MasterCard, Visa or Discover, responsible for managing transactions over the network and for arbitration of any disputes. For more information, see the Key Concepts Guide.

3-digit code on the magnetic strip of a card which indicates where it is valid for use.

The Card Transaction System (CTS) enables you to test the integration of your card processing systems and validate the setup of your External Host Interface (EHI).

This is a 3-digit number which is located on the card’s magnetic stripe tracks 1 and 2. It is used to help prevent fake magnetic stripe transactions, but is vulnerable to copying if someone can see the original magnetic stripe data. See also Card Verification Value/Code 2 (CVC2 or CVV2). For more information, see Managing Risk.

This is a 3-digit number which is located on the card’s magnetic stripe tracks 1 and 2. It is used to help prevent fake magnetic stripe transactions, but is vulnerable to copying if someone can see the original magnetic stripe data. See also Card Verification Value/Code 2 (CVC2 or CVV2). For more information, see Managing Risk.

Card Verification Code 3 (Mastercard) / dynamic Card Verification Value (Visa) are dynamic values which are used to secure Contactless Magnetic Stripe Transactions. They are similar to a small EMV Application Cryptogram, which is placed in the discretionary data (track 2) in the place of the CVC2 on the magnetic stripe sent to the card scheme (network). For more information, see Managing Risk.

Consumer or account holder who is provided with a card to enable them to make purchases. For more information, see the Key Concepts Guide.

Cardinal Commerce provide an Access Control Server (ACS) that enables support for the 3D Secure cardholder authentication scheme. See: https://www.cardinalcommerce.com
For more information on the Thredd 3D Secure service via Cardinal, see the 3D Secure Guide - RDX Biometric Guide.

Cardinal Commerce provide an Access Control Server (ACS) that enables support for the 3D Secure cardholder authentication scheme. See: https://www.cardinalcommerce.com
For more information on the Thredd 3D Secure service via Cardinal, see the 3D Secure Guide - RDX Biometric Guide.

Clearing House Automated Payment System (CHAPS) is a bank-to-bank payment system that provides irrevocable, settlement risk-free, and efficient payments. CHAPS guarantee same-day payment – as long as payment instructions are received by a specific time in the working day (the time is determined by your bank). It is typically used for high value payments, as there is no limit to the amount of money that you can transfer via CHAPS. For more information, see the Key Concepts Guide.

Where a cardholder disputes a transaction on their account and is unable to resolve directly with the merchant, they can raise a chargeback with their card issuer. The chargeback must be for a legitimate reason, such as goods and services not received, faulty goods, or a fraudulent transaction.
For more information, see the Payments Dispute Management Guide.

Thredd receive batch clearing files from the card networks, containing clearing transactions, such as presentments and network fees. The card issuer transfers the requested settlement amount to the acquirer and 'clears' the amount on the card, reducing the available card balance accordingly. For more information, see the Key Concepts Guide.

A Software as a Service (SaaS) capability which acts as the Identity Provider (IDP) for Thredd’s interfaces (including Raidiam Connect and Thredd Portal), and as an OAuth OpenID Provider (OP) for the registration and management of customer applications, generation and validation of access tokens, and for the enforcement of access control policies. For more information, see the Connecting to Thredd Guide.

Online merchant Token Requestors are referred to as Card on File (COF) Token Requestors. For more information, see the Tokenisation Service Guide.

The number of sessions (concurrent requests) that can be processed by the Thredd server at the same time. This figure may vary, depending on server load and performance, which affects the response time. For example, an average server response time of 0.05ms. For more information, see the External Host Interface Guide.

A proprietary data element that specifies which cryptographic algorithm is employed during transaction processing. The CVN is included in the Issuer Application Data (IAD) and can influence how cryptographic keys are derived and how transaction data is processed. Different versions of CVN correspond to different processing methods and security protocols used by various card schemes, such as Visa or MasterCard.

The Card Verification Value 2 (CVV2) or Card Validation Code 2 (CVC2) on a credit card or debit card is a 3 digit number on VISA, MasterCard branded credit and debit cards. Cardholders are typically required to enter the CVV2 during any online or cardholder not present transactions.

The Developer Portal enables users to sign up and gain access to the Sandbox environment, where developers can trial our REST API using the API Explorer or a Postman Collection. For more information on how to get access, refer to the Developer Portal.

The PAN value set up on the cardholder’s device. This is not visible to the cardholder, but is the PAN used for the transactions as far as the merchant is concerned.

The score applied by the wallet provider defining the level of satisfaction the wallet provider has in the request being a genuine cardholder attempt, based on the wallet providers internal fraud parameters. For more information, see the Tokenisation Service Guide.

A Direct Debit is an instruction from a customer to their bank, authorising an organisation to collect payments from their account, as long as the customer is given advance notice of the payment amounts and payment dates. For more information, see the Key Concepts Guide.

The Discover Global Network consists of a group of card networks acquired by Discover. This includes: Discover, Diners Club International and Pulse. For more information, refer to the Discover Global Network.

Device PAN. The PAN value set up on the cardholder’s device. This is not visible to the cardholder, but is the PAN used for the transactions as far as the merchant is concerned. For more information, see the Tokenisation Service Guide.

European Economic Area.

For authorisation types of transactions, the External Host Interface (EHI) can operate in one of four modes:

• Gateway Processing: Mode 1 - the External Host maintains card balances and participates in transaction authorisation by approving or declining the transaction.
• Cooperative Processing: Mode 2 - Thredd maintains balances and performs all types of the authorisation, but the External Host can overrule in some circumstances.
• Full Service Processing: Mode 3 - read-only data feed from the Thredd system to the Client's system.
• Gateway Processing with STIP: Mode 4 - External Host maintains Balance (with Thredd stand-in).

For more information, see the External Host Interface Guide.

EMV is a payment standard for smart payment cards, payment terminals and automated teller machines (ATMs). EMV is an acronym for "Europay, Mastercard, and Visa", the three companies that created the standard. EMV cards are smart cards, also called chip cards, integrated circuit cards, or IC cards which store their data on integrated circuit chips, in addition to magnetic stripes for backward compatibility.
For more information, see the Key Concepts Guide.

An 8-byte number derived from a secret key and transaction data, used to secure EMV chip card (including EMV contactless) transactions. The Issuer (or Visa/Mastercard) will verify the number and, if correct, the Application Cryptogram provides integrity and authentication, since it proves that the transaction data has not been altered and that it was generated by the real card (as only the real card has the secret key).

• If the card requests that the transaction is sent for online authorisation, then the Application Cryptogram is called an ARQC (Authorisation ReQuest Cryptogram).
• If the card declines the transaction, then the Application Cryptogram is called an AAC (Application Authentication Cryptogram).
• If the card approves the transaction, then the Application Cryptogram is called a TC (Transaction Certificate).

Organisation that facilitates worldwide interoperability and acceptance of secure payment transactions. Created by EuroPay, Mastercard and Visa.

When a card with a fixed validity period, such as a gift card, expires, the available funds on the card are charged as an expiry breakage fee. The actual money is shared between Thredd and the Program Manager.

The external system to which Thredd sends real-time transaction-related data. The URL to this system is configured within Thredd per programme or product. The Program Manager uses their external host system to hold details of the balance on the cards in their programme and perform transaction-related services, such as payment authorisation, transaction matching and reconciliation. For more information, see the External Host Interface Guide.

The External Host Interface provides a facility to enable exchange of data between Thredd and external systems via our web services. All transaction data processed by Thredd is transferred to the External Host side via EHI in real time. For certain types of transactions, such as Authorisations, the External Host can participate in payment transaction authorisation. For more information, see the External Host Interface Guide.

Groups which control the card transaction authorisation fees, and other fees, such as recurring fees and Thredd web service API fees. For more information, see the Fees Guide.

A card usage fee type that defines the fees that are applied to a specific type of transaction, such as a debit card payment or an ATM withdrawal. A Fee Group will consist of one or more fee types. For more information, see the Fees Guide.

The 16-digit PAN of the card, which Mastercard/Visa converts when authorisations come through to them from Acquirers on the DPAN. For more information. For more information, see the Tokenisation Service Guide.

A financial reversal occurs when the acquirer cancels all or part of a prior transaction (which may be a purchase, refund, cashback, cash, PIN change, or any other transaction type). For example, if the acquirer has already taken the funds and are aware of a processing error (e.g., double charging), they can submit an 1240 Financial Reversal. For more information, see the External Host Interface Guide.

The fraud rate is the percentages of transactions received by the acquirer which are identified as fraudulent. For example, if 10,000 transactions per day are received, and 10 of these are identified as fraudulent, the fraud rate would be 0.01.

Controls the rates for FX currency conversions if the purchase currency is different from the card's currency. For more information, see the Fees Guide.

This is an Apple term for a Token Provisioning request that is approved. For more information, see the Tokenisation Service Guide.

The period of time during which Thredd waits for an approved authorisation amount to be settled. This is defined at a Thredd product level. A typical default is 7 days for an auth and 10 days for a pre-auth. For more information, see the External Host Interface Guide.

Card Verification Value/Code for an Integrated circuit card. This is a 3-digit number placed on an EMV chip card in the Track 1 and Track 2 data elements on it, in place of the Magnetic Stripe CVC1/CVV1 value. It helps secure EMV chip transactions if the issuer is unable to verify the Application Cryptogram. It ensures that anyone seeing the EMV chip track data elements cannot know the CVC1/CVV1 which is present on the magnetic stripe; See Card Verification Value/Code 1.

Purchase or activity made or available from within a particular app on a mobile device, without the need to visit a separate online site. For more information, see the 3D Secure Guide.

A request for an additional amount on a prior authorisation. An incremental authorisation is used when the final amount for a transaction is greater than the amount of the original authorisation. For example, a hotel guest might register for one night, but then decide to extend the reservation for additional night. In that case, an incremental authorisation might be performed in order to get approval for additional charges pertaining to the second night. For more information, see the External Host Interface Guide.

An industry standard format for card-based transaction messages. Three different versions exist: 1987, 1993 and 2003. Different varieties of this are used for Visa Authorisation message, Mastercard Authorisation messages, and Mastercard Clearing messages. For more information, see the Tokenisation Service Guide.

The card issuer, typically a financial organisation authorised to issue cards. The issuer has a direct relationship with the relevant card scheme (payment network). For more information, see the Key Concepts Guide.

Thredd Issuer (Program Manager) code, assigned by Thredd . Each Program Manager is assigned their own unique issuer code on the system. For more information, see the Key Concepts Guide.

This is the host connected directly to Visa/Mastercard for authorisation messages (i.e., Thredd ). For more information, see the Tokenisation Service Guide.

The Issuer Identifier Number (IIN) Bank is the term used in countries such as Japan for a Bank Identification Number (BIN); this is the first four or six numbers on a payment card, which identifies the institution that issues the card.

Interactive Voice Response System. Typically a telephony-based system, where the user calls in and selects options via an automated voice prompt.

Velocity limit group which restricts the frequency and/or amount at which the card can be loaded or unloaded. You can view your current Limit Groups in Thredd Portal or Smart Client. For more information, see the Key Concepts Guide.

The MAC length typically refers to the size of a MAC (Message Authentication Code) in cryptographic contexts. The length of a MAC can vary depending on the specific algorithm being used. Common MAC lengths are 128, 160, and 256 bits depending on the specific method used.

The card’s magnetic stripe, which stores data on a band of magnetic material on the card. The magnetic stripe is read by swiping a magnetic reading terminal.

A type of Thredd card that is restricted to loading and unloading to a physical or virtual card and cannot be used for e-commerce or in-store transactions. An MVC is used to reflect the value of the ‘actual’ money in the Issuer's bank account. An MVC guarantees that the load is limited to the amount prefunded (i.e. loaded onto MVC) and gives the Program Manager the ability to distribute funds immediately rather than having to wait for notification of each individual load into the Issuer Bank account.

Mastercard's Automatic Billing Updater (ABU) is a service that automatically updates card information for recurring payments and stored card details. it can be used can be used for updating card information in cases such as expired cards, replaced cards and changes in billing address.

Mastercard Chip and PIN Application, is a specification developed by Mastercard for the secure processing of transactions using EMV (Europay, Mastercard, and Visa) chip cards. It outlines the protocols and standards for card authentication, transaction processing, and data security in environments where chip-and-PIN is used.

The MasterCard Digital Enablement Service (MDES) is a data interchange platform for generating and managing secure digital payment tokens. It enables devices such as smartphones, smart watches, as well as merchants, to create a tokenised version of a Mastercard, which is specific to that device or merchant. Then the device/merchant can use the tokenised version of the card to perform transactions. The tokenised version of the card appears as just a normal Mastercard card number to the merchant and acquirer, and Mastercard will map the transactions onto the original cardholder Mastercard. For more information, see the Tokenisation Service Guide.

Mastercard processing hardware and software system that interfaces with Mastercard's Global Payment System communications network. For more information, see the Tokenisation Service Guide.

Enables smaller networks to use Mastercard as a routing platform for payments. Can also be referred to as MNEX or MNGS. For more information, see the Key Concepts Guide.

Merchant Category Code (MCC) Group. The MCC is a four-digit number used by the Card Schemes to define the trading category of the merchant. The MDES platform is used in iPhone 6, iPhone 6 Plus and Apple Watch to enable secure payments to take place for contactless and in-app payments. You can configure your cards to allow/disallow payments based on the merchant's MCC. For more information, see the Key Concepts Guide.

The shop or store providing a product or service that the cardholder is purchasing. A merchant must have a merchant account, provided by their acquirer, in order to trade. Physical stores use a terminal or card reader to request authorisation for transactions. Online sites provide an online shopping basket and use a payment service provider to process their payments. For more information, see the Key Concepts Guide.

Merchant account, which an Acquiring bank provides to a merchant to enable them to take card payments. For more information, see the Key Concepts Guide.

Merchant category codes (MCCs) are four-digit numbers that describe a merchant's primary business activities. MCCs are used by credit card issuers to identify the type of business in which a merchant is engaged. For more information, see the Key Concepts Guide.

The Thredd core Message Processor module performs a number of key roles: receives and processes authorisation and financial messages from the schemes; runs internal transaction screening and validation checks on authorisation messages; processes messages; provides the authorisation decision; checks the internal balance ledger to determine if sufficient funds are available and updates the balance ledger; applies card fees ; initiates other related services, such as authentication and transaction reporting. For more information, see the Key Concepts Guide.

Figure 1-4: Thredd Message Processor

The Message Type Identifier (MTI) is a four digit number used for card originated financial transactions. The MTI standard is defined by ISO 8583. For each message, it identifies: version number, message class, message function and transaction originator. For details. see the figure below.

Figure 1-5: Message Type Identifier (MTID) Format

Payment card which supports payment and settlement transactions in multiple currencies. The MFX card typically has a single PAN with multiple currency wallets linked.

A token requestor connected to a mobile device. For more information, see the Tokenisation Service Guide.

Near Field Communication (NFC) is a technology that enables a device, such as a mobile phone or payment ring, to transmit data to a Point of Sale (POS) terminal, enabling contactless payments.

This is often used in scenarios where the merchant terminal is not required to request authorisation from the card issuer (for example for certain low risk, small value transactions used by airlines and transport networks). The card CHIP EMV determines if the offline transaction is permitted; if not supported, the terminal declines the transaction. Note: Since the balance on the card balance is not authorised in real time, there is a risk that the card may not have the amount required to cover the transaction. For more information, see the External Host Interface Guide.

One Time Passcode/ Activation code which is sent to the cardholder for use in authenticating during token provisioning, during the setup of Google Pay, Apple Pay or other wallet on their device. For more information, see the Tokenisation Service Guide.

A token requestor that is an e-commerce merchant. For more information, see the Tokenisation Service Guide.

This is an Apple term for a Token Provisioning request that is approved, but with a request for further enhanced verification and with Wallet Reason 16 ("High fraud risk, enhanced verification recommended") set. For more information, see the Tokenisation Service Guide.

OOB authentication is a type of two-factor authentication that requires a secondary verification method through a separate communication channel along with the typical ID and password. For example, the user may be asked to respond to an automatically-generated phone call, enter a code sent to their smartphone or provide biometric verification via voice or fingerprint. For more information, see the 3D Secure Guide.

An additional amount or fee charged on a transaction, typically used to hedge against FX currency fluctuations or mitigate risks of higher declines or chargebacks for certain merchant categories.

Some acquirers support a partial amount approval for Debit or Prepaid payment authorisation requests. The issuer can respond with an approval amount less than the requested amount. The cardholder then needs to pay the remainder using another form of tender. For more information, see the External Host Interface Guide.

A transaction where the merchant requests authorisation for an initial or partial amount. This may be followed by authorisation requests for additional amounts.

End-to-end testing of the cardholder journey using real cards that have been issued, which takes place before a service is rolled-out to customers. For more information, see the Getting Started Guide.

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organisations that handle credit cards from the major card schemes. All Program Managers who handle customer card data must be compliant with this standard. See: https://www.pcisecuritystandards.org/pci_security/
For more information, see the Key Concepts Guide.

The second payment services directive (PSD2) is an EU Directive which sets requirements for firms that provide payment services. It introduces a number of requirements around how firms treat their customers and handle their complaints, and the data they must report to the FCA.

An institution which offers payment services to customers, whether they are businesses or retail consumers. Includes banks, building societies, e-money institutions and payment institutions. As defined in the Payment Services Regulations 2017.

Thredd term for a MDES/VDEP token. This is used to differentiate between a Thredd public token and a MDES/VDEP token. Thredd use this in EHI and web service calls to identify a particular DPAN. For more information, see the Tokenisation Service Guide.

The default set of parameters Thredd will use to authorise a Token Activation Request (TAR). For more information, see the Tokenisation Service Guide.

The token requestor specific set of parameters Thredd will use to authorise a Token Activation Request (TAR). For more information, see the Tokenisation Service Guide.

The Payment Card Industry Data Security Standard (PCI DSS) is an information security standard for organisations that handle credit cards from the major card schemes (payment networks). All Program Managers who handle customer card data must be compliant with this standard. See: https://www.pcisecuritystandards.org/pci_security/

The technical process of marking private data specific to a given card or device. The same terminology is used when putting private data on a chip card or a smart device. For more information, see the Key Concepts Guide.

A hardware device for processing card payments at retail stores. The device has embedded software that is used to read the card’s magnetic strip data. For more information, see the Key Concepts Guide.

Transaction where the merchant requests authorisation for an initial or estimated amount. This may be followed by an Authorisation advice to confirm the final amount or authorisation requests for additional amounts.

Stage in a transaction where the funds authorised on a card are captured (deducted from the cardholder’s account). See also Clearing. Also referred to as the First presentment. For more information, see the External Host Interface Guide.

Figure 1-6: Presentment Flow

Pretty Good Privacy (PGP) is an encryption program that provides cryptographic privacy and authentication for data communication. PGP is used for signing, encrypting, and decrypting texts, e-mails, files, directories, and whole disk partitions and to increase the security of e-mail communications.
PGP is used for encrypting the card image in a virtual card. For more information, see the Virtual Cards Guide.

The Primary Account Number (PAN) is the card identifier found on payment cards, such as credit cards and debit cards, as well as stored-value cards, gift cards and other similar cards. The card’s 16-digit PAN is typically embossed on a physical card. For more information, see the Key Concepts Guide.

Card product-level master record. For more information, see the Key Concepts Guide.

The Product Setup Form is a spreadsheet that provides details of your Thredd account setup. The details are used to configure your Thredd account. For more information, see the Getting Started Guide.

The predefined reference code associated with the card, which is included in the XML file sent to the card manufacturer. For more information, see the Web Services Guide.

Logical grouping of your products set up on the Thredd Platform. This is set up with whatever the customer (issuer or program manager) wants. Can be viewed in reports or via the web services API and may also be sent to the card manufacturer. For more information, see the Key Concepts Guide.

A Thredd customer who manages a card program. The program manager can create branded cards, load funds and provide other card or banking services to their end customers. For more information, see the Key Concepts Guide.

The Project Initiation Document (PID) is put together at a start of a project. This document outlines the initial project requirements and parties involved. For more information, see the Getting Started Guide.

The Project Requirements Document (PRD) provides full details of the requirements of your project. Project schedules and implementation are based on the details provided in this document. For more information, see the Getting Started Guide.

The Project Scoping Document (PSD) defines the scope of the project and is typically produced before the start of the project. For more information, see the Getting Started Guide.

The Thredd 9-digit token is a unique reference for the PAN. This is used between Thredd and clients to remove the need for Thredd clients to hold actual PANs. For more information, see Thredd Public Token.

The process of pre-authenticating the cardholder prior to a token request being sent to Visa. For more information, see the Tokenisation Service Guide.

Mastercard report which provides details needed for quarterly reporting to the Scheme, and includes details such as the number of live cards, card issued, and information on card activity and status. For more information, contact your Thredd Implementation Manager or Account Manager.

When two separate processes are reading and updating a value at the same time, then the latest process can overwrite the previous saved result.

Thredd's self-signing Certificate Authority (CA) and SaaS capability for the creation and management of certificates. These include: Transport Certificates, Signing Certificates and Encryption Certificates. For more information, see the Connecting to Thredd Guide.

This is an Apple term for a Token Provisioning request that is declined. For more information, see the Tokenisation Service Guide.

A refund transaction occurs when a merchant refunds a customer part or all of a previously purchased item. Refunds are standalone transactions that have their own lifecycle (financial message and possibly authorisation message). The refunds may be linked with a previous purchase or not, as there is no strict linking requirement for refunds against previous purchases. For more information, see the External Host Interface (EHI) Guide.

Process of responding to a chargeback raised by an issuer, where the acquirer or merchant do not agree with the chargeback and wish to dispute it via the card scheme. For more information, see the Payments Dispute Management Guide.

A public-private (asymmetric) cryptographic algorithm. When RSA is used, it can refer to:

• The RSA Algorithm (e.g., used on chip cards to prove the card is real by Offline Data Authentication)
• The RSA Company (www.rsa.com) which Thredd use as one provider of identity and Access management solutions. See: https://www.rsa.com/

The Thredd Sandbox is a REST API environment the enables customers to trial our REST endpoints. Credentials to access the Sandbox can be acquired by signing up to the Developer Portal. With these credentials you can trial different REST endpoints in either the API Explorer in our Cards API documentation, or using our Postman Collection.

Controls whether a card is charged a recurring fee, such as a monthly platform fee. For more information, see the Fees Guide.

Card scheme-level master record, used when setting up a program manager on the Thredd system. For more information, see the Key Concepts Guide.

When a merchant resubmits the transaction with evidence to counter the chargeback. For more information, see the Payments Dispute Management Guide.

Secure File Transfer Protocol. File Transfer Protocol (FTP) is a popular unencrypted method of transferring files between two remote systems. SFTP (SSH File Transfer Protocol, or Secure File Transfer Protocol) is a separate protocol packaged with SSH that works in a similar way but over a secure connection.
SFTP is used for sending XML reports to customers. For more information, see the Transaction XML Reporting Guide and Balance XML Reporting Guide.

SOAP is a messaging protocol for exchanging structured information in the implementation of web services. It uses Extensible Markup Language (XML) for its message format and relies on application layer protocols such as HTTP for message negotiation and transmission. SOAP allows developers to invoke processes running on disparate operating systems (such as Windows, macOS, and Linux) to authenticate, authorise, and communicate using XML. For more information, see the Web Services Guide.

Smart Client is Thredd's legacy desktop application for managing your account on the Thredd Platform. For more information, see the Smart Client Guide.

An issuer can use a soft decline if they receive a request from a merchant to authorise a payment, but they want to use authentication first. For more information, see the 3D Secure Guide.

An SSL certificate displays important information for verifying the owner of a website and encrypting web traffic with SSL/TLS, including the public key, the issuer of the certificate, and the associated subdomains.

The card network (Visa and Mastercard) may approve or decline a transaction authorisation request on behalf of the card issuer. Depending on your Thredd mode, Thredd may also provide STIP on your behalf, where your systems are unavailable. For more information, see the External Host Interface Guide.

For more information on status codes returned via EHI, see the External Host Interface Guide. For more information on status codes used for web services, see the Web Services Guide.

Strong Customer Authentication (SCA) requires a combination of two factors of identification at checkout. Examples include something they know (such as a password or PIN), something they get (such as an OTP in a mobile phone or other device) or something they are (such as their fingerprint). For more information, see the 3D Secure Guide.

SAFE is a Mastercard initiative requiring card issuers to report all cardholder fraud claims. The data sent to Mastercard is used to help identify and track fraudulent activity. See: https://globalrisk.mastercard.com/online_resource/system-to-avoid-fraud-effectively-safe-compliance-program/
For more information on Thredd support for SAFE reporting, see the Thredd Fraud Reporting Guide.

Thredd Protect is a legacy fraud-management service that enables you to set up powerful configuration rules for handling transactions in almost realtime. Thredd Protect receives transaction data from the Thredd Platform and makes automated decisions based on the business logic you have configured. Check with your Thredd account manager for details.

The name of the high-level product type set up in Thredd , usually at a BIN level. For more information, see the Key Concepts Guide.

Thredd Portal is Thredd's new web application for managing your cards and transactions on the Thredd Platform. For more information, see the Thredd Portal Guide.

Thredd’s Secure Connectivity Framework is the combination of several components which enable secure access to Thredd’s resources, using a common identity store. For more information, see the Connecting to Thredd Guide.

Tokenisation Complete Notification. Sent from Mastercard/Visa to Thredd and made available via EHI to the Program Manager to confirm the setup of the token was successful (note: there may be further messages for activation). For more information, see the Tokenisation Service Guide.

Tokenisation Event Notification. Informs the issuer of unsuccessful Activation Code entry attempts and subsequent invalidation of an Activation Code or when a token is suspended, resumed or de-activated. For more information, see the Tokenisation Service Guide.

This is the entity that stores the mapping between the PAN and the token. With the existing Thredd integration, this would be Visa. For more information, see the Tokenisation Service Guide.

Tokenisation is a security technology which replaces the sensitive 16-digit permanent account number (PAN) that is typically embossed on a physical card with a unique payment token (a digital PAN or DPAN) that can be used in payments and prevents the need to expose or store actual card details. For more information, see Tokenisation.

Figure 1-7: Tokenisation

Tokenisation Authentication Value (TAV). Used as part of In-app provisioning process and is the encrypted message that contains the PAN details for Mastercard from the Program Manager. For more information, see the Tokenisation Service Guide.

Tokenisation Authorisation Request messages enable the issuer to provide a real-time decision as to whether the token service provider (MDES/VDEP) can digitise a card and designate a token on their behalf. For more information, see the Tokenisation Service Guide.

Transport Layer Security (TLS) is a security protocol that provides privacy and data integrity for Internet communications. Implementing TLS is a standard practice for building secure web apps.

Triple DES (3DES or TDES), is a symmetric-key block cipher, which applies the DES cipher algorithm three times to each data block to produce a more secure encryption.

Group that controls where a card can be used. For example: POS or ATM. For more information, see the Web Services Guide.

Checks that are performed to confirm the card is valid, such as CHIP cryptograms, mag-stripe data (if available) and expiry date.

Thredd offers a virtual card service, which cardholders use online, without needing a physical card. For more information, see the Virtual Cards Guide.

Virtual Data Element, used for 3D Secure identification. Examples are memorable name, memorable place and memorable date. For more information, see the 3D Secure Guide.

The function that allows online merchant token requestors to bind their existing COF token to a device.  This product is designed to improve security and reduce friction at checkouts. For more information, see the Tokenisation Service Guide.

Outlines the requirements for conducting secure contactless transactions at point-of-sale (POS) devices.

Visa Digital Enablement Programme.  Also called the Visa Tokenisation Service (VTS). For more information, see the Tokenisation Service Guide.

Visa Dispute Resolution Online system, provided by Visa for managing transaction disputes. For more information, see the Payments Dispute Management Guide.

A set of standards covering aspects of transaction processing such as security protocols, data formats, and communication methods between payment devices and networks.

The Visa Test Simulator is used by Issuers and Acquirers to test their programmes that interact with the Visa Online Authorisation System. For more information, see the Tokenisation Service Guide.

Visa Tokenisation Service is the Visa product name for tokenisation and equivalent of Mastercard’s MDES (see MDES). Thredd refer to this service as the Visa Digital Enablement Program (VDEP). For more information, see the Tokenisation Service Guide.

Token requestors are sometimes also referred to as wallet providers. These are providers such as Apple, Android (Google), Samsung etc. who supply the payment apps (also known as Mobile Wallet token requestors). For more information, see the Tokenisation Service Guide.

Webhooks provide a robust platform for efficient event-driven interactions, retrieving notification details, subscribing to events, and re-sending notifications. You can use the Thredd REST API to create and update webhook endpoints, and specify desired events for notification for the endpoints. For more information see the Cards API Website: Introduction to Webhooks.

Controls the fees charged for web service usage. Different web services can have different fees associated with them. For more information, see the Fees Guide.

Web Service Definition Language (WSDL) is an XML format for describing network services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented information. WSDL files are central to testing SOAP-based services. For more information, see the Web Services Guide.

This is an Apple term for a Token Provisioning request that is approved, but with a request for further authentication. For more information, see the Tokenisation Service Guide.