2.4 GetTransaction Message Fields

Acquirer_id_DE32

Acquiring Bank ID as assigned by the network. Note that the format differs depending on whether this is an Authorisation or a Financial type message.

For Authorisation messages:

• 2 digits length of Acquirer ID (01 to 09)

• Acquirer ID (possibly with leading zeros)

For Financial messages:

• 6 digit Acquirer ID (possibly with leading zeros)

Examples:

Authorisation examples:

• “06123456” means:  “06” = length of Acquirer ID.  “123456” Acquirer ID.

• “0501234” means: “05”=length of acquirer ID. “01234” = acquirer ID.

Financial examples:

• “123456”  (acquirer id = 123456)

• “00123” (acquirer id = 123)

N(3,15)

ActBal

Actual balance on the card after the transaction, in the card account currency:

• Positive indicates a credit balance.

• Negative indicates a debit balance.

AmountSigned(19,4)

Additional_Amt_DE54

DE 54 (Additional Amounts) provides information on up to two amount types and related account data. See Additional Amount Field.

AN(20,120)

Amt_Tran_Fee_DE28

DE 28 (Amount, Transaction Fee) is the fee charged (for example, by the acquirer) for transaction activity in the transaction currency code. The format differs between Authorisation and Financial messages, as follows:

• Authorisation message format: D= debit issuer or C = credit issuer; 8 digit fee amount in the minor units of currency held in the field Txn_CCy.

• Financial message format: Number in the major units of currency held in the field Txn_CCy, with decimal places.

Authorisation:

AN(9,9)

Financial:

AmountUnsigned(9,2)

Auth_Code_DE38

Authorisation code generated by Thredd for approved and declined authorisation requests.

ANP(1,6)

Avl_Bal

Available balance on the card after the transaction, in the currency of Bill_Ccy field (card account currency). Negative indicates the account is in debit.

AmountSigned(19,4)

Bill_Amt

Settlement billing amount of the transaction in Bill_Ccy currency.

Positive indicates the cardholder account is to be credited (e.g. used for Refunds). Negative means that cardholder account is to be debited (e.g. used for Purchase transactions). For usage in transactions, see Examples of Amount Signs.

Note: This excludes the Thredd calculated fees (Fee_Fixed and Fee_Rate) and Padding (Fx_Pad and MCC_Pad). Financial Transactions do not have padding.

AmountSigned(19,4)

Bill_Ccy

ISO 3-digit numeric currency of the billing amount. See Currency Codes.

N(3,3)

BlkAmt

Total amount blocked on the card after this transaction, in the card's account currency (Bill_Ccy field). Normally zero (if no blocked amount on the card) or negative. For example:

• If BlkAmt = 0.0000 the total amount blocked on this card for all outstanding transactions is 0.0000.

• If  BlkAmt = -24.0100 the total amount blocked on this card for all outstanding transactions is 24.0100 in the Bill_Ccy currency.

AmountSigned(19,4)

Cust_Ref

Customer account reference.

ANS(1,25)

FX_Pad

Foreign currency (FX) padding applied to the transaction in the card's account currency (Bill_Ccy field).

AmountUnsigned(19,4)

Fee_Fixed

The total fixed fee amount which is the sum of all fixed fees calculated by Thredd (based on your Thredd Fee Group Groups which control the card transaction authorisation fees, and other fees, such as recurring fees and Thredd web service API fees. configuration). This is applied to the transaction in the card's account currency (Bill_Ccy field). Normally zero or positive.

AmountSigned(19,4)

Fee_Rate

Fee amount due, including all percentage rate fees calculated by Thredd applied to the transaction. Normally zero or positive. Corresponds to your fee setup on the system.

AmountSigned(19,4)

LoadSRC

The source of the load request. See Load Source.

Present only for Txn_Type values of:
L= Load; U = Unload; G = Payment

N(1,4)

LoadType

Payment method of funds for the load. See Load Types.

Present only for Txn_Type values of:

L= Load; U = Unload; G = Payment

N(1,1)

MCC_Code

The classification (card acceptor business code or merchant category code) of the merchant’s type of business or service. See Merchant Category Codes.

N(1,4)

MCC_Desc

The classification (card acceptor business code or merchant category code) of the merchant’s type of business or service.

ANS(0,250)

MCC_Pad

Merchant category code (MCC) padding applied for the transaction in the card's account currency (Bill_Ccy field).

AmountUnsigned(19,4)

Merch_ID_DE42

Identifies the merchant or entity that accepted the card. This is always provided for a POS transaction and is optional for an ATM transaction.
For a POS tansaction, the merchant name is defined by the acquirer (Acquirer_id_DE32). For an ATM transaction, it typically identifies the entity that owns the ATM.

ANS(1,15)

Merch_Name_DE43

Identifies the merchant or entity that accepted the card and their location (excluding ATM and card-activated public phones).

Note: For EHI Version 3.0 and beyond, Thredd recommend using the following fields: Merch_Name, Merch_Street, Merch_City, Merch_Region, Merch_Postcode, Merch_Country.

The format differs depending on whether this is an Authorisation or a Financial message. For Visa and Mastercard authorisation message formats, see Merch_Name_DE43 Field in Authorisations. For Visa and Mastercard financial message formats, see Merch_Name_DE43 Field in Financials.

ANS(1,101)

Note

Note for the particular transaction. Notes are taken from transaction details appended during each type of transactions. For declined transactions, this might occasionally have text explaining why the transaction was declined.

ANS(0,500)

POS_Data_DE22

Point of Sale (POS) data field, indicating the PAN entry method and the capability of the terminal to accept a PIN.

Note: For EHI Version 3.0 and beyond, Thredd recommend using the following fields: GPS_POS_Capability, GPS_POS_Data.

Format and content differs per message type as follows:

For Visa and Mastercard Authorisation messages:

• This holds the PAN entry method and PIN capture capability. See POS_Data_DE22 in Authorisation Messages

• For the extra POS methods and capabilities, see field POS_Data_DE61 instead

For Mastercard Financial messages: this holds all the POS methods and capabilities. See POS_Data_DE22 in Mastercard Financial Messages.

For Visa Financial messages:  this is empty.

Authorisation messages:

N(3,4)

Financial messages:

AN(12,12)

POS_Data_DE61

Note: For EHI Version 3.0 and beyond, Thredd recommend using the following fields for accurate POS data: GPS_POS_Capability and GPS_POS_Data.
The is because POS_Data_DE61 is only relevant to Mastercard authorisations and only the first 9 positions are guaranteed in Mastercard.

For Mastercard authorisation-related messages: This holds additional POS condition codes. See POS_Data_DE61 Values

For Visa Authorisation-related messages: this is empty.

For Financial and all other messages: this is empty.

ANP(9,39)

POS_Termnl_DE41

Uniquely identifies the terminal which accepted the card. Always present if the card data was read by a terminal (i.e. field POS_Data_DE22 first two digits are any of: 02,03,04,05,06,07,08,80,90,91,92,95.)

Otherwise may be omitted.

ANS(1,8)

POS_Time_DE12

This is the local time or date/time of the transaction in the time zone of the merchant or entity that accepted the card. The format varies depending on the message type as follows:

For Authorisation messages (Transaction Type – Authorisation), the format is:

“hhmmss” (hh=hour 00-23,  mm=minute 00-59,  ss=second 00-59.)

Note: For Visa Authorisations, the time is optional, so this field may be blank.

For Financial messages (Transaction Type – Financial, including dummy offline authorisations), the format is:

“YYMMDDhhmmss” (YY=last 2 digits of year, MM=month 01-12, DD=day of month 01-31, hh=hour 00-23, mm=minute 00-59, ss=second 00-59.)

Note: For Visa Financial format, the time is often “000000”, so often only the YYMMDD will have a meaningful value.

If Auth:

N(6,6) or blank

If Financial (inc. dummy auth):

N(12,12)

Proc_Code

Processing code for the transaction. See Processing Codes.

N(6,6)

Resp_Code_DE39

This field is provided in 0120 (auth advice), 0400 (reversal request) and 0420 (reversal advice) messages to indicate the reason for the advice or reversal. You should check this field to determine whether the transaction was STIP approved or declined. For more information, see Resp_Code_DE39 Values.

Note: For some Visa authorisation advices, this field is optional, so may be blank.

AN(2,2)

Ret_Ref_No_DE37

Document reference number supplied by the system. Retains the original source document of the transaction and assists in locating that source document.

ANP(1,12)

Settle_Amt

Settlement amount in settlement currency, as received from the Network. Value varies per transaction types as follows:

MTID/Txn_Type combinations listed in the section Transaction Type – Authorisation (auths, auth reversals):

• the amount is always positive

• The amount is the network converting the transaction amount into the settlement currency, and is not the net settlement amount

MTID and Txn_Type combinations listed in the section Transaction Type – Financial (real financials and their reversals, dummy Auths):

• The amount will have the same sign as the Bill_Amt field:  positive (e.g., 20.00) if the card is credited and negative (e.g., -20.00) if debited.

• This amount will not include interchange or issuer fees – it is simply the transaction amount converted into the settlement currency by the network, then the sign adjusted to positive or negative. It is not the net settlement amount.

For usage in transactions, see Examples of Amount Signs.

AmountSigned(19,4)

Settle_Ccy

Settlement currency. ISO 3-digit numeric. See Currency Codes.

N(3,3)

Status_Code

Current status code of the card on the Thredd system. See Card Status Codes.

AN(2,2)

Token

Thredd public token of the card. The range includes values from 100000000 to 999999999 inclusive.

N(1,9)

Trans_link

An identifier used to link related transactions together. For details, see the Trans_Link Field Appendix.

N(1,19)

Txn_Amt

Transaction amount, in the transaction currency (see Txn_CCy field). Always zero or positive. To identify whether this is a credit or debit, check the Proc_Code field. For usage in transactions, see Examples of Amount Signs.

AmountUnsigned(19,4)

Txn_CCy

Currency in which transaction occurred. ISO 3-digit currency code. See Currency Codes.

N(3,3)

Txn_Ctry

Country code for the transaction. ISO 3-alpha country code. Upper case characters only.See Country Codes.

A(3,3)

Txn_Desc

Description of the transaction.

ANS(1,800)

Txn_GPS_Date

Date in which transaction occurred. It is 'GMT' in winter and 'GMT +1' in summer (BST stands for British Summer Time). Format:

YYYY-MM-DD hh:mm:ss.nnn

Where there is a space between the date and time fields, and nnn is the milliseconds.

For TransactionType = A and MTID = 0100, this date is the time at the point just before Thredd sends the transaction to EHI.

Datetime (Y_to_nnn)

TXn_ID

Unique ID for the transaction, generated by Thredd. This should be used for duplicate checking. Maximum number will be 2⁵³-1.

N(1,16)

Txn_Stat_Code

Transaction status code for the transaction. See Transaction Status Codes.

AN(1,1)

TXN_Time_DE07

Transmission Date and Time, in GMT (UTC) timezone.

Date and time message was sent by the acquirer to MasterCard/Visa Network. Format:

MMDDhhmmss

Where:

MM = Month of year 01-12

DD = Day of month 01-31

hh = hour of day 00-23

mm = minute of hour 00-59

ss = second 00-59

N(10,10)

Txn_Type

Transaction type description for the transaction. See Transaction Types.

AN(1,1)

Additional_Data_DE48

Network Additional data DE48 field. Contact Thredd if there is any specific piece of information you need from here.

Ignore unless mutually agreed with Thredd to extract certain data.

For certain sub-elements, Thredd may use a default value of "3" to replace the original content to keep the integrity of the data field. If your organisation is using a specific sub-element contained within a data field with a default value, please contact your Thredd account manager.

ANS(1,5000)

Authorised_by_GPS

To identify whether authorised by Thredd or not for Stand-In enabled products:

Y = Thredd can stand-in to authorise transaction in agreed circumstances.

N = no stand-in authorisation

A(1,1)

AVS_Result

The result of AVS checking. See AVS Results.

AN(1,1)

CU_Group

Group code assigned for usage checking.

ANS(1,10)

InstCode

Thredd Issuer (Program Manager) Code. Assigned by Thredd.

ANS(1,4)

MTID

The Message Type Identifier (MTID) describes the type of message being interpreted.

0100 = Authorisation Request

0400 = Reversal Request

0420 = Reversal Advice

1240 = Financial Notification (also used for Chargeback Notification for Mastercard and Visa; check TransactionType to tell the difference)

'05 ' (05 with 2 spaces) = Financial Notification (Purchase from Visa)

'06 ' (06 with 2 spaces) = Financial Notification (Credit from Visa)

'07 ' (07 with 2 spaces) = Financial Notification (Cash from Visa)

'25 ' (25 with 2 spaces) = Financial Reversal (of a Purchase from Visa)

'26 ' (26 with 2 spaces) = Financial Reversal (of a Credit from Visa)

'27 ' (27 with 2 spaces) = Financial Reversal (of Cash from Visa)

For a full list, see Transaction Matching Criteria.

ANP(1,4)

ProductID

This value is the Product ID of the card. The Product ID is generated during product setup. For details, check with your Implementation Manager.

N(1,5)

Record_Data_DE120

This field is Mastercard-specific. DE 120 (Record Data) is a variable-length data element used for transmitting file record data or textual character string data in various message types.

ANS(1,1000)

SubBIN

The sub-BIN value assigned to the product.

Can only be used for 6-digit BINs. Displays the 6-digit BIN plus 2 additional sub-BIN digits.

For 8-digit BINs, displays the 8-digit BIN.

N(1,11)

TLogIDOrg

ID of original transaction for reversals.
Maximum value will be 2⁵³-1.

N(1,16)

VL_Group

Group code assigned for velocity checking.

ANS(1,10)

Dom_Fee_Fixed

Domestic fixed fee amount applied to transaction by Thredd, in the card account currency. It is part of the Fixed_Fee.

Domestic is defined as: Txn_CCy = Bill_Ccy

Corresponds to your fee setup on the system.

AmountSigned(19,4)

Non_Dom_Fee_Fixed

Non-domestic fixed fee amount applied t othe transaction by Thredd, in the card account currency. It is part of Fixed_Fee.

Non-Domestic is defined as: Txn_CCy ≠ Bill_Ccy

Corresponds to your fee setup on the system.

AmountSigned(19,4)

Fx_Fee_Fixed

Fixed foreign exchange fee amount applied by Thredd to the transaction, in the card account currency. It is part of Fixed_Fee. Corresponds to your fee setup on the system.

For example, if:

• the “Fx Fixed” was “1.2000” (i.e., 1.20 in billing currency) in the fee configuration relevant for this transaction

• Bill_Amt=10.0000

• Txn_CCy = 840

• Bill_Ccy = 826

• Foreign exchange occurred (as Txn_Ccy ≠ Bill_Ccy)

then Fx_Fee_Fixed Amount = 1.2000 (in account currency)

AmountSigned(19,4)

Other_Fee_Amt

Other fees applied. It is part of Fixed_Fee.

AmountSigned(19,4)

Fx_Fee_Rate

Fee Amount calculated by Thredd as part of the transaction, due to “Fx Rate” fee setting. It is part of Fixed_Fee.

Corresponds to your fee setup on the system.

For example, if:

• the “Fx Rate” was “1.2000” (i.e., 1.20%) in the fee configuration relevant for this transaction

• Bill_Amt=10.0000

• Txn_CCy = 985

• Bill_Ccy = 840

• Foreign exchange occurred (as Txn_CCy ≠ Bill_Ccy)

then Fx_Fee_Rate Amount = 10.0000 * 0.0120 = 0.1200 (in account currency)

AmountSigned(19,4)

Dom_Fee_Rate

Fee Amount calculated by Thredd as part of the transaction, due to “Dom Fee Rate” fee setting, in the card account currency. It is part of Fixed_Fee.

Domestic is defined as: Txn_CCy = Bill_Ccy

Corresponds to your fee setup on the system.

For example, if:

• The “Dom Fee Rate” fee setting was “1.7500”

• Bill_Amt = 32.0000

• Txn_CCy = 978

• Bill_Ccy = 978

• Transaction is Domestic (as Txn_CCy = Bill_Ccy)

Then Fee Amount due to “Dom Fee Rate” = 32.0000 * 0.0175 = 0.5600  (in account currency.)

AmountSigned(19,4)

Non_Dom_Fee_Rate

Fee Amount calculated by Thredd, due to Non domestic rate fee setting, in the card account currency. It is part of Fee_Rate.

Non-Domestic is defined as: Txn_CCy ≠ Bill_Ccy

Corresponds to your fee setup on the system.

For example, if:

• The “Non Dom Fee Rate” fee setting was “2.00” (i.e. 2%)

• Bill_Amt = 64.0000

• Txn_CCy = 840

• Bill_Ccy = 826

• Transaction is non-domestic (as Txn_CCy ≠ Bill_Ccy)

Then Fee Amount due to “Non Dom Fee Rate” = 64.0000 * 0.0200 = 1.2800  (in account currency.)

AmountSigned(19,4)

Additional_Data_DE124

This field is Mastercard specific. DE 124 is used only for MasterCard Money Send and transactions.

In a Mastercard Networks Exchange SMS Network, acquirers can use DE 124 (Mastercard Networks Exchange Tags, Acquirer/Info, Text) to pass additional information to issuers on financial requests.

ANS(1,200)

CVV2

Cardholder Verification Value 2. This will only be present if configured for the customer. Format of this if present will be:

• If 3 characters long: 3 digit CVV2 value

• If 6 characters long:

Position 1 (CVV2 presence indicator)
Position 2 (CVV2 Response Type indicator)Position 3 (Space)

Positions 4–6 ( CVV2 Value)

(Thredd always sends the 3-digit CVV2 values for Mastercard.  For Visa Threddsends the 6-character version)

N(3,6)

Expiry_Date

Card or Token expiry date as received in transaction. Format: YYMM

This will only be present if configured for by the Program Manager.

N(4,4)

PAN_Sequence_Number

PAN sequence number. Only present if sent by the acquirer.

N(1,2)

PIN

PIN block of format PIN_Format (see PIN Block Formats) encrypted under the EHI PIN Key of index = PIN_Key_Index using algorithm PIN_Enc_Algorithm.

Present only if Online PIN message and customer is configured to receive it. If this field is present, then these fields will also be present:

• PIN_Key_Index

• PIN_Format

• PIN_Enc_Algorithm

HEX(32,32)

PIN_Enc_Algorithm

PIN block encryption algorithm.

Describes the encryption algorithm used to encrypt the PIN in the PIN field. Values:

• 3DES = Triple DES using ECB, using a triple length DES key.

Note: Other values may be added in future versions.

(This field is always present if PIN field is present)

AN(1,16)

PIN_Format

The format of the PIN block used as clear text before encryption to create the PIN field. PIN Block formats:

0 = ISO9564-1 Format 0

1 = ISO9564-1 Format 1

2 = ISO9564-1 Format 2

3 = ISO9564-1 Format 3

Currently only value ‘1’ (implying ISO9564-1 Format 1) is supported. This is because it is the only PIN block format that varies for the same PIN and does not require a PAN.

(This field is always present if the PIN field is present)

N(1,4)

PIN_Key_Index

Index of the PIN Key used to encrypt the PIN field.

(This field is always present if the PIN field is present)

N(1,4)

SendingAttemptCount

Indicates the number of times Thredd has repeated this message:

0 = not repeated (1st transmit)

1 = repeated once (2nd transmit)

2 = repeated twice (3rd transmit)

…

n = repeated n times ((n+1) transmit)

N(1,4)

source_bank_ctry

Note: This is Mastercard-specific.

Source Bank Country code as ISO 3-alpha uppercase. See Country Codes.

A(3,3)

source_bank_account_format

Format of the bank account number in the source_bank_account field. See Bank Account Format.

AN(1,8)

source_bank_account

Source bank account number. In format specified by source_bank_account_format

ANP(1,34)

dest_bank_ctry

Destination Bank Country code as ISO 3-alpha uppercase. See Country Codes.

A(3,3)

dest_bank_account_format

Format of the bank account number in the dest_bank_account field. See Bank Account Format.

AN(1,8)

dest_bank_account

Destination bank account number. In format specified by dest_bank_account_format. See Bank Account Format.

ANP(1,34)

GPS_POS_Capability

Thredd defined POS Capability codes. Defines what the POS terminal capabilities are for this transaction. See GPS_POS_Capability.

AN(2,255)

GPS_POS_Data

Thredd defined POS Data codes. Defines what happened at the POS terminal (e.g. card data input method). See GPS_POS_Data field.

AN(1,255)

Acquirer_Reference_Data_031

Acquirer Reference Number (ARN). 

This field is a 23 digit number for Mastercard and Visa transactions and an 8-digit alphanumerical value for Discover Global Network transactions.

The acquirer reference number exists for clearing messages only (Financial advices/notifications, and Chargeback advices/notifications (and reversals of)).

If MTID=1240 and Txn_Type=’A’ (dummy auth created if no matching auth to the financial) – in this case there may or may not be Acquirer_Reference_Data_031 present.

It is created by the acquirer in the first financial presentment, according to the scheme rules.  It will be the same value for all clearing messages in the entire lifecycle.

Note: Values should be unique per card scheme within a 10-year time period.

N(23)

Response_Source

Indicates which system sent the 0110 or 0210 response to the terminal. Normally present only for some Authorisation advices and Authorisation reversals.

See Response_Source and Message_Source values.

The field is ANS, but the special character is restricted to ‘_’ (underscore) and ‘-‘ (minus sign), and special character will not begin the string.

ANS*(1,10)

Special characters only ‘-‘ or ‘_’

Response_Source_Why

Indicates the reason why the Response_Source sent a response to the terminal. Normally present only for some Authorisation advices and Authorisation reversals. See Response_Source_Why and Message_Why values.

N(1,4)

Message_Source

Indicates which system sent this message. Normally present only for some Authorisation advices and Authorisation reversals.

See Response_Source and Message_Source values.

The field is ANS, but the special character is restricted to ‘_’ (underscore) and ‘-‘ (minus sign), and special character will not begin the string.

ANS*(1,10)

Special characters only ‘-‘ or ‘_’

Message_Why

Indicates the reason why Response_Source sent a response to the terminal. Normally present only for some Authorisation advices and Authorisation reversals. See Response_Source_Why and Message_Why values.

N(1,4)

traceid_lifecycle

Lifecycle Trace ID. This consists of alphanumeric and ‘-‘ characters only. This is a value assigned to the lifecycle of the transaction, which is identical for all messages relating to the same transaction. For example, the following messages relating to the same transaction will all have the same Lifecycle Trace ID value: Authorisation, Second incremental authorisation, authorisation reversal, Financial Presentment, Chargeback, Second Presentment and Second chargeback.

If there is more than one authorisation for the same transaction, both authorisations will have the same value.

This is a reliable matching field and should be used for matching in the first instance if present.

Construction of this field's value

The traceid_lifecycle is a concatenation of: network_id + "-" + date_yyyymmdd + "-" + a unique identifier

For more information, see the FAQs: What is the traceid_lifecycle field and how is it constructed?

Note: We strongly advise you not to use hard-coded logic on your side based on the current format of this field, as Thredd may change the format of this field in the future.

Note: Will be present in most messages, but may not be included in some Authorisation Reversals (e.g. timeout reversals) and some Financial messages which were not authorised online (e.g. refunds, offline approved transactions).

ANS*(1,40)

* * the only special character is "-" (hyphen)

Balance_Sequence

Thredd balance sequence number. Incremented by 1 each time the actual_balance or blocked_amount of the card account changes on the Thredd system.

Maximum value =2⁶³-1.

This gives the external host an idea of how out-of-sync the Thredd actual_balance and blocked_amount fields are compared to the external host.

This will always be present in any transaction where external host can respond with a Balance Update (Update_Balance=1 in response.)  This happens only in online transactions sent to EHI as soon as Thredd receives them (not for after-the-event transactions sent later to EHI via a queue mechanism at Thredd, e.g., presentments.)

N(1,19)

Max value is 2⁶³-1.

Balance_Sequence_Exthost

The external host balance sequence number received from the EHI response. See field ‘New_Balance_Sequence_Exthost’ in the section Response Field Formats.

Maximum value = 2⁶³-1.

Maintained by the External host.

This tells the external host how recent Thredd’s external balance is.  A higher number indicates a more recent balance.

This field will always be present in any transaction where external host can respond with a Balance Update (Update_Balance=1 in response.)

This happens only in online transactions sent to EHI as soon as Thredd receives them (not for after-the-event transactions sent later to EHI via a queue mechanism at Thredd, e.g., presentments.)

N(1,19)

Max value is 2⁶³-1.

PaymentToken_id

Unique Thredd ID of the payment token. Only present if transaction relates to a payment token (for example, Apple Pay).

N(1,10)

PaymentToken_creator

Identifies which system created the payment token.Only present if the transaction relates to a payment token (for example, Apple Pay).

See Response_Source and Message_Source.

AN(1,10)

PaymentToken_expdate

Expiry date of the payment token. Only present if the transaction relates to a payment token (for example, Apple Pay). Format YYYY-MM-DD

Note: In the case of a Token Replacement message (MTID=’0100’, Txn_Type=’A’, Proc_Code=’360000’, Message_Why=52) then this contains the *new* payment token expiry date.  (The previous payment-token expiry date is currently not included.)

Datetime(Y_to_D)

PaymentToken_type

The type of system the payment token is encoded onto (defines how the payment token PAN is held). Only present if the transaction relates to a payment token (for example, Apple Pay). See PaymentToken_type.

Note: not to be confused with the device type (PaymentToken_deviceType).

AN(1,10)

PaymentToken_status

Current status of the payment token as set by Thredd. Only present if the transaction relates to a payment token (for example, Apple Pay). See Card Status Codes.

AN(1,2)

PaymentToken_creatorStatus

Current status of the payment token as set by the creator of the payment token. Only present if the transaction relates to a payment token (for example, Apple Pay). See PaymentToken_creatorStatus.

AN(1,1)

PaymentToken_wallet

Wallet that the payment token belongs to. Only present if the transaction relates to a payment token (for example, Apple Pay). See PaymentToken_wallet.

AN(1,10)

PaymentToken_deviceType

Indicates the type of the device in which the payment token is held. Only present if the transaction relates to a payment token (for example, Apple Pay). See PaymentToken_deviceType.

AN(1,10)

PaymentToken_lang

The ISO 639-1 2 character alpha language code reported by the payment token device at digitisation time. Only present if the transaction relates to a payment token (for example, Apple Pay). For a list of ISO 639-1 language codes, see http://www.iso.org

Note: this may not be known, in which case the field will be empty.

A(0,2)

PaymentToken_deviceTelNum

The telephone number of the device on which the payment token is present, as reported by the creator at digitisation time. Only present if the transaction relates to a payment token (for example, Apple Pay).

Note: this may be empty, a full or partial number, and may be masked in various ways as the creator and/or wallet provider determines.

ANS(0,15)

PaymentToken_deviceIp

IPv4 address of the device on which the payment token is present, as reported by the creator at digitisation time. Only present if the transaction relates to a payment token (for example, Apple Pay).

May arrive in either of 2 formats:

Hex format: PPQQRRSS

Where:

• PP = 1st IP byte, as 2 hex digits (00 to FF)

• QQ=2nd IP byte, as 2 hex digits (00 to FF)

• RR=3rd IP byte, as 2 hex digits (00 to FF)

• SS=4th IP byte, as 2 hex digits (00 to FF)

Or decimal format: p.q.r.s

Where:

• p = 1st IP byte, in decimal (0 to 255)

• q = 2nd IP byte, in decimal (0 to 255)

• r = 3rd IP byte, in decimal (0 to 255)

• s = 4th IP byte, in decimal (0 to 255)

Note: each decimal number may be prefixed with 0, 1 or 2 leading zeros, up to a maximum of 3 decimal digits (eg byte “4” could be encoded as “4”, “04” or “004”.

ANS(1,15)

PaymentToken_deviceId

Payment token device ID as reported by the Wallet service provider. Only present if the transaction relates to a payment token (for example, Apple Pay).

ANS(0,48)

PaymentToken_deviceName

Payment token device name as given by the device owner (i.e., cardholder). Only present if the transaction relates to a payment token (for example, Apple Pay).

ANS(0,20)

PaymentToken_activationCode

Activation code that the cardholder must enter into the payment token holding device to complete Tokenisation. Only present if the first two characters of Proc_Code=“34” (payment token activation notification)

AN(1,8)

PaymentToken_activationExpiry

The Date and Time in UTC (GMT) that the activation code in the field PaymentToken_activationCode expires. Only present if the first two characters of Proc_Code=“34” (payment token activation notification).

Note: milliseconds are present, but will always be zero.  For Mastercard, seconds will always be zero.

Datetime(Y_to_nnn)

PaymentToken_activationMethodData

Data to indicate the value corresponding the selected PaymentToken_activationMethod. Only present if the first two characters of Proc_Code=“34” (payment token activation notification). See PaymentToken_activationMethod.

ANS(1,255)

PaymentToken_activationMethod

The method by which the cardholder should obtain the Activation Code (in the field PaymentToken_activationCode) which they must enter into the device holding the payment token in order to activate it. Only present if first two characters of Proc_Code=“34” (payment token activation notification). See PaymentToken_activationMethod.

N(1,4)

ICC_System_Related_Data_DE55

EMV Chip data in TLV hex format:

• Hexadecimal digits (0-9 and A-F) where 2 hexadecimal digits represent 1 byte, where the encoded bytes mean:

  • EMV TLV data as Tag, Length, Value bytes encoded as Basic Encoding Rules (BER) as described in EMV Book 3 Annex B, Rules for BER-TLV data objects.

• Note that all tags sent from the acquirer will be present (even if not defined by EMV)

Example ( if sending tags 9F35 and 82)

9F35012282021980

For format of Tag, Length and Value:  See EMV Book 4.3 (www.emvco.com) Annex B – “Rules for BER-TLV Data Objects”

For definitions of Tags, see the following:

• EMV Book 3 Annex A – Data Elements Dictionary

• EMV Book 3 Annex C – Coding of Data Elements Used in Transaction Processing

• EMV Book 3 Annex A – Coding of Terminal Data Elements

For the definition of tag 9F10, and any tag in the range 9F50 – 9F7F inclusive, see the specification of the EMV chip card application that are used by the card.

HEX(0,512)

Merch_Name

Merchant (or ATM owner) name. Many sources limit the Merchant/ATM-owner name to between 22 to 25 characters.

ANS(0,40)

Merch_Street

Merchant/ATM street address. Not always provided.

ANS(0,80)

Merch_City

Merchant/ATM city. Many sources limit the city name at 13 characters

ANS(0,40)

Merch_Region

Merchant/ATM region code. Defines a sub-region of a country.  Usage varies per country. Not always provided.

If Merch_Country=USA, this will be a 2-alpha US state code (e.g. “AK” for Alaska). If Merch_Country=CAN (i.e. Canada) this will be a  2-alpha Canadian province code  (e.g. “QC” for Quebec).

Other countries may put a region code in here.

ANS(0,3)

Merch_Postcode

Merchant or ATM postal code. Postal code existence and format varies country to country. Not always provided.

ANS(0,20)

Merch_Country

Merchant or ATM country code. ISO 3-alpha country code. See Country Codes.

Inclusion of this field is typically optional, but may be mandatory, depending on the program or service being processed. For more information, refer to the Card Scheme documentation.

A(3)

Merch_Tel

Merchant (or ATM operator) telephone number.

Provided occasionally by some merchants

ANS(25)

Merch_URL

Merchant website URL. Provided by some merchants.

ANS(255)

Merch_Name_Other

Alternative merchant name. This could be the Sole Trader or Legal name if provided.

ANS(40)

Merch_Net_id

Merchant ID assigned by Visa or Mastercard. The card networks assign unique merchant IDs to some merchants (generally larger ones).

ANS(30)

Merch_Tax_id

Merchant’s Tax ID (reference), if provided.

ANS(30)

Merch_Contact

Merchant alternative contact details. Provided occasionally.

(For example, may contain an email address, secondary phone numbers, customer service operation hours and contact name.)

ANS(30)

auth_type

Type of authorisation request, as indicated by the acquirer. 

0 = normal/undefined

P = Preauth (amount will be an estimate)

F = Final auth (amount is correct and for the full amount.  No incremental auths will be received after this.)

V = Account Verification

Blank/empty = not applicable (e.g. for non-authorisation message types).

Note: See auth_expdate_utc below for how long the authorisation block should survive.)

AN(1,1)

auth_expdate_utc

Expiry date and time of this authorisation in UTC/GMT, as set by the acquirer or estimated by Thredd. This field only applies to Authorisations and Authorisation Advices (MTID/Txn_Type combinations: ’0100’/’A’  or ‘0120’/’J’.) For both, this is when the authorisation expires, but note the following:

• If the auth_type field indicates a pre-auth (value ‘P’) then this will be the UTC/GMT time when the pre-auth expires. It is calculated from the time Thredd receives the pre-auth, then adding the number of days the acquirer indicates it should survive for.

• If the auth_type field is not pre-auth (not ‘P’) then this is Thredd’s estimate of how long the authorisation should survive.  It may not be 100% accurate (as Thredd may be unaware of all timeliness criteria, which can be changed at any time by Visa/Mastercard.)

Datetime(Y_to_nnn)

Matching_Txn_ID

For Authorisation Reversals, Incremental Authorisations, Incremental Authorisation Reversals and first presentments this is set to the TXn_ID field of the original authorisation that this transaction Thredd matched it to.

For all other transactions, it will be blank.

Maximum value is 2₅₃-1.

For offline authorisations or where Thredd does not receive an original authorisation due to any reason, Thredd will not populate the Matching_Txn_ID field.

N(1,16)

Reason_ID

For various messages, this contains a value explaining the reason for the message.

• For chargebacks, it contains the chargeback reason.

• For Visa authorisation-related messages, it contains the Visa Message Reason Code (from Visa Base 1 field 63.3)

• For other messages, it may describe the reasons for these.

See Reason ID.

Maximum value: 9999

N(1,4)

Dispute_Condition

Additional information, in addition to Reason_ID field.

For Visa chargebacks, it contains the Visa Dispute Condition.

For other messages, it is currently not used. See Dispute Condition.

ANS(1,3)

Network_Chargeback_Reference_Id

The reference numbers assigned by VISA or MasterCard during VROL or Mastercom initiated chargebacks.

N(1,19)

Acquirer_Forwarder_ID

Identifies the acquiring institution forwarding a Request or Advice message.

N(1,11)

Currency_Code_Fee

Currency code of the interchange fee. ISO 3-digit currency code. See Currency Codes.

N(3,3)

Currency_Code_Fee_Settlement

Currency code that the interchange fee will be settled in. ISO 3-digit currency code. See Currency Codes.

N(3,3)

Interchange_Amount_Fee

Interchange fee amount in the currency defined in Currency_Code_Fee. The interchange fee is an additional amount charged by the Card Scheme, Issuer or Acquirer. For example:

• POS transactions — positive interchange fee is paid to the issuer

• ATM transactions — negative interchange fee is paid to the operator of the ATM

• ATM card capture — fee is paid to the operator of the ATM

• Stolen card fee — interchange fee is paid to the issuer

These fees are only finalised at the presentment stage when settlement and transfer of funds occurs. You should factor your fee structure in line with potential network fees.

AmountSigned(15,6)

Interchange_Amount_Fee_Settlement

Interchange fee amount in the currency defined in Currency_Code_Fee_Settlement.

AmountSigned(15,6)

Clearing_Process_Date

Indicates the clearing system’s processing date expressed in the local time zone of the clearing system’s processing centre. This is referred to as the Reconcilliation Date in the Thredd Transaction XML (for details, see the Transaction XML Guide).

Datetime(Y_to_D)

Settlement_Date

Identifies the date when the schemes settlement services initiate the movement of funds for settlement.

Note: This date may be different from Clearing_Process_Date if files are processed on days which settlement banks are closed.

Datetime(Y_to_D)

DCC_Indicator

Indicates whether Dynamic Currency Conversion (DCC) has taken place.

0 = DCC has not been performed

1 = DCC has been performed

N(1,1)

multi_part_txn

Indicates whether the message is any part of a multi-auth/clearing sequence. 

0 = Message is not part of a multi-auth/clearing sequence or no information was received from the acquirer

1= Message is any part of a multi-auth/clearing sequence

Note: This field is as received by Thredd; if the value received from the acquirer is blank, then the field is populated with 0.

N(1,1)

multi_part_txn_final

Indicates whether the message is the final part of a multi-auth/clearing sequence.

0 = Message is not the final part of a multi-auth/clearing sequence or no information was received from the acquirer

1 = Message is the final part of a multi-auth/clearing sequence

Note: This field is as received by Thredd; if the value received from the acquirer is blank, then the field is populated with 0.

N(1,1)

multi_part_number

Only available for Visa transactions. Indicates what part of a multi-auth/clearing sequence the message is.  This value will not be higher than the total parts in multi_part_count field.

0 = N/A or unknown part number.

N(2,2)

multi_part_count

Only available for Visa transactions. Indicates how many parts there are in the multi-auth/clearing sequence. 

0 = N/A or unknown.

N(2,2)

SettlementIndicator

Defines what settlement service the network will use to settle transactions:

0 = International Settlement Services

3 = Clearing Only

4 = Bilateral Settlement

8 = National Net Settlement Services

N(1,1)

Network_TxnAmt_To_BillAmt_Rate

The card network’s currency conversion rate that they used to convert Txn_Amt into Bill_Amt. The rate used will be associated with the Network_Currency_Conversion_Date field. There will normally be seven significant figures in the rate, as that is what Visa and Mastercard currently send.

Rate

Network_TxnAmt_To_BaseAmt_Rate

The card network’s currency conversion rate used to convert Txn_Amt into the network’s base amount (often in US Dollars). This can be used in conjunction with Network_BaseAmt_To_BillAmt_Rate to understand how the Network converted Txn_Amt into Bill_Amt.

For Visa Base2, this is what arrives in Draft Data TCR5’s Source Amount to Base Amount conversion rate field; there will always be six significant figures.

Note: The network Base Amount is not provided, as Thredd do not receive this.

Rate

Network_BaseAmt_To_BillAmt_Rate

The card network’s currency conversion rate used to convert from the network’s base amount (often in US Dollars) to the Bill_Amt.

This can be used in conjunction with Network_TxnAmt_To_BaseAmt_Rate to understand how the Network converted Txn_Amt into Bill_Amt.

For Visa Base2, this is what arrives in Draft Data TCR5’s Base Amount to Destination Amount conversion rate field; there will always be six significant figures.

Note: The network Base Amount is not provided, as Thredd do not receive this.

Rate

POS_Date_DE13

Terminal local date of transaction. The network normally provides the date as MMDD, and Thredd will add YYYY which most likely corresponds to it. MMDD will be transmitted exactly as received, even if invalid.

Thredd will set the YYYY to ‘0000’ if MMDD received is not a valid date.

DatetimeRaw(Y_to_D)

Traceid_Message

The card network’s reference. Data reflects exactly what was received.

• Mastercard: date is from DE15, reference is from DE63 (exactly as provided.)

• Visa: date is from Transaction ID DE62.2, reference is Transaction ID DE62.2 (exactly as provided)

This should always be valid, except for a Visa message if the acquirer provided an invalid value.

TraceidRaw

Traceid_Original

The card network’s original reference. Data reflects exactly what was received, and may or may not be valid.

• Mastercard: date MMDD is from DE48.63 positions 10-13, with YYYY completed by Thredd (or ‘0000’ if MMDD is not a valid date.  Reference is from DE48.63 positions 1-9.

• Visa: date is from Original Transaction ID DE125, dataset 3 Tag 3, reference is Original Transaction ID DE125, dataset 3 Tag 3 (exactly as provided)

TraceidRaw

Network_Currency_Conversion_Date

The card network’s currency conversion date. Reflects the date of Visa/Mastercard currency conversion rate used in the transaction came from. MMDD is supplied by the network, Thredd add the corresponding year YYYY.  If the MMDD received from the network is not a valid date, Thredd will set YYYY to ‘0000’.

DatetimeRaw(Y_to_D)

Mastercard_AdviceReasonCode_DE60

Mastercard Authorisation Advice Reason Code (field 60).

Explains why Mastercard Stand-In processing (STIP) occurred or why an advice was created.

This field has a length of 999, but currently Mastercard send a maximum of 60. Format:

• First 3 digits = Advice Reason Code – this indicates the main reason for the advice

• Next 4 digits: Advice Detail Code – generally ‘0000’ indicates ‘Accept’ (e.g. by STIP or X-Code), and all other values indicate a decline/error detail

• Everything else: Advice Detail text – human readable text message

See Mastercard_AdviceReasonCode_DE60.

ANS(1,999)

Network_Original_Data_Elements_DE90

The raw network data present in online reversals to explain which original (MTID=0100) the reversal is referring to. Format:

This is provided to aid diagnostics in exception cases.

Note: This field is as received by Thredd; data accuracy depends on the acquirer.

N(42,42)

Visa_ResponseInfo_DE44

Visa Base1 field 44 – Visa’s Additional Response Data, exactly as provided from Visa to Thredd. This will only be present for transactions received by Thredd from Visa Base1, if DE44 was present.

It provides information on Visa’s validation checks of data in the message. This will only be set for Visa online authorisation transactions.

ANS(25)

Visa_STIP_Reason_Code

Visa Base 1 field 63.4 STIP/Switch Reason Code. This maybe present for Visa online authorisation advices and reversals, to explain why Visa STIP responded instead of Thredd. This will only be set for Visa online authorisation-related transactions (MTID=0120 and MTID=0420).

N(4,4)

Network_Issuer_Settle_ID

The card network's ID of the institution responsible for settlement.

• For Mastercard: Member ID (ICA) of the Issuer responsible for the transaction (IPM DE93).

• For Visa: Funds Transfer Settlement Reporting Entity (Base 2 TCR33 Clearing and Settlement Advice, TCR0, 140-149)

N(6,11)

Network_Replacement_Amounts_DE95

DE95 replacement amounts from the card network. Used in reversals and completion advices to advise of the new amounts.

Format for Mastercard:

• Positions 1-12: Actual transaction amount in minor units.

• Positions 13-24: Actual settlement amount in minor units

• Positions 25-36: Actual cardholder billing amount in minor units

• Positions 37-42 fixed '000000'.

Format for Visa:

• Positions 1-12: Actual transaction amount in minor units.

• Positions 13-42: Not used (zero filled)

AN(42,42)

Visa_POS_Data_DE60

Visa Base 1 field 60 – Additional POS Data. Thredd already map the Visa POS data into the GPS_POS_Data and GPS_POS_Capability fields, which Thredd recommend to use in preference. This will only be set for Visa online authorisation transactions.

Note: the raw Visa POS Data is also provided for extra information.

N(2,12)

Network_Transaction_ID

The raw transaction ID, exactly as received from the card network without any alteration. Present only if received. Thredd load this as follows:

• Visa Online: 16 hexdigits of the DE62.2 Visa Transaction ID. The leading hexdigit should be a ‘0’ padding character.  (Format HEX(16,16).)

• Visa Clearing: 15 characters, which should all be digits. (15 ‘0’ characters indicates unknown.)  (Format N(15,15).)

• Mastercard Online: DE63 concatenated with DE15 (Format ANS(1,13))

• Mastercard Clearing: DE63 (Format ANS(1,16))

Note: Thredd provide this to aid resolving exception messages. Thredd recommend you use traceid_lifecycle instead.

ANS(1,16)

Misc_TLV_Data

Miscellaneous data. See section Misc_TLV_Data field.

Note: Thredd expect you to normally ignore this field.

It is used to contain rarely used pieces of data that are not normally required for transaction processing. The field maximum is 8000, however in EHI 4.1, we never expect this to be more than 200.

TLV10(0,8000)

Acquirer_Country

If present, contains the ISO 3-alpha uppercase country code of the acquirer.

Note: This field is available on EHI version 5.0 and beyond.

A(3,3)

PaymentToken_PanSource

Describes the originator of a Tokenisation Authorisation Request. For possible values, see PaymentToken_PanSource.

Note: This field is available on EHI version 5.0 and beyond.

AN (1,1)

ClearingFileID

Populated for Clearing records. Shows the File ID of the file that contains the presentment record.

Note: This field is available on EHI version 5.0 and beyond.

ANS (1, 50)

Network_Fraud_Data

Contains Fraud or Risk Indicators received from the card network.

See Network_Fraud_Data Format.

Note: This field is available on EHI version 5.0 and beyond.

AN (1, 32)

SenderData

Contains the sender details in a money transfer message (Visa OCT or Mastercard Money Send)

This field is represented as a Tag-Length-Value (TLV) TLV is an encoding scheme. A TLV-encoded record contains the record type (tag), followed by record Length, and finally the Value itself. Example: 0104John where: tag type = 01 (first name) tag length = 4 digits tag value = John record with the following order and lengths:

• Tag - two characters

• Length - two decimal digits

• Data - the number of characters as given by the length

See SenderData and ReceiverData Fields.

Note: This field is available on EHI version 5.0 and beyond.

ANS (1, 512)

ReceiverData

Contains the receiver details in a money transfer message (Visa OCT or Mastercard Money Send).

This field is represented as a Tag-Length-Value (TLV) TLV is an encoding scheme. A TLV-encoded record contains the record type (tag), followed by record Length, and finally the Value itself. Example: 0104John where: tag type = 01 (first name) tag length = 4 digits tag value = John record, with the following order and lengths:

• Tag - two characters

• Length - two decimal digits

• Data - the number of characters as given by the length

See SenderData and ReceiverData Fields.

Note: This field is available on EHI version 5.0.

ANS (1, 512)

AuthenticationAmountUpper

The maximum authentication amount in the currency specified in the AuthenticationCurrency, as provided during a 3D Secure 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/Visa Secure’ and ‘Mastercard SecureCode/Mastercard Identity Check’ respectively. authentication session. This field can be used to confirm whether the amount that was submitted for authentication is the same as the amount that was submitted for authorisation. For details, see Checking fields used for 3D Secure Authentication.

Note: For Visa, the authentication amount is the exact amount authenticated.

For Mastercard, if AuthenticationAmountUpper is a value of 14000 or below in the minor units of currency, then it is exact.
If AuthenticationAmountUpper is a value of more than 14000 in the minor units of currency, then it is the maximum possible Authentication Amount from the approximate value that Thredd received from Mastercard.

AmountUnsigned(14,4)

AuthenticationCurrency

The 3-digit authentication currency code, used for AuthenticationAmountUpper.

N(3,3)

AuthenticationMerchantHash

A hash of the merchant name as received at the authentication stage, in decimal digits or hex digits. For Visa, this is the Information Data provided by the Access Control Server (ACS), which may contain the merchant name hash, '00000000' or an IP address1 For Visa, this is the hashed value of Merchant Name as provided in the Authentication Request (data element ‘merchantName’ in AReq) or Payer Authentication Request (DTD element ‘Merchant.name’ in PAReq) message. SHA-256 to be used, first 8 numerical digits (digits 0 through 9) from the result of hashing to be used. If 8 numerical digits are not found, subtract 10 from all character digits (digits A through F) and use the first result(s) for as many digits missing of the 8 digit value.. For Mastercard, this field contains the hash (using SHA 256) of the merchant name.

AN (8,8)

Responsestatus

Response Code for the authorisation request. See Responsestatus Values.

Note:If sending value “10” (partial approval), then response field Bill_Amt_Approved must be provided too.

AN(2,2)

CurBalance

Actual balance on card after the transaction. Positive means the card is in credit. Negative means the card is in debit.

AmountSigned(9,2)

AvlBalance

Available balance on card after the transaction. Positive means the card is in credit. Negative means the card is in debit.

AmountSigned(9,2)

Acknowledgement

Notification message for the transaction is acknowledged or not. Valid values are:

0 = Not Acknowledged (i.e. Thredd should re-transmit this); 1 = Acknowledged

N(1,1)

LoadAmount

This column must contain the amount that needs to be loaded to the card if approval is with an '0A' (Approve with Load) response code. Applicable only to Cooperative Processing (mode 2) with ‘Approve with Load’ feature set on.

AmountUnsigned(9,2)

Bill_Amt_Approved

Contains the amount approved in the billing currency code (Bill_Ccy.)

This is mandatory for all partial approval messages, to inform the acquirer how much of the transaction amount is approved.

Note that partial approval (Resp_Code_DE39="10") is only permitted if GPS_POS_Capability position 1 (partial approval support indicator) is 1 (partial approval supported by POS)

It should have the same sign as Bill_Amt in the request message. However, Thredd will take the absolute value of this (for example, sending -52.64 is the same as sending 52.64).

AmountSigned(9,2)

Update_Balance

Indicates whether Thredd should update stand-in balances.

0=do not update balance (default); 1=update balance (using CurBalance_GPS_STIP and AvlBalance_GPS_STIP as provided in this response)

Note: You should only respond with ‘1’ (update balance) if you have received both Balance_Sequence and Balance_Sequence_Exthost in the request message.

Note: the Thredd stand-in balances can also be updated via the WS_BalanceUpdate web service or the Cards API The Thredd Cards API is a new REST-based API which can be used to connect to the Thredd system in place of using the traditional Thredd SOAP-based Web Services. The REST API provides messages in JSON format. If you are interested in the Cards API, please contact your Account Manager. Card Balance Adjustment endpoint.

N(1,1)

New_Balance_Sequence_Exthost

New external host balance sequence number for this card account.

New balance (and this New_Balance_Sequence_Exthost number) to be installed if both Update_Balance=1, AND this balance sequence number is strictly higher than the existing external host balance sequence number (CARDS.bal_seqno_exthost). Use of this will prevent Thredd from installing an out-of-date balance.

External host usage:

• Each time the external host returns a balance, it should include this number.

• The external host should increment this number each time it changes the card balance.

• Numbers do not need to be sequential.

• Thredd interprets a higher number as indicating a more recent balance

Example:

External host sends Thredd two response messages:

Message A: CurBalance=11.11; AvlBalance=22.22; Update_Balance=1

New_Balance_Sequence_Exthost = 18

Message B: CurBalance=77.77 ; AvlBalance=88.88; Update_Balance=1

New_Balance_Sequence_Exthost=20

Since the New_Balance_Sequence_Exthost in message B is higher than message A, Thredd will always apply the balances from Message B, irrespective of which message is received first.

N(1,19)

Max possible value is 2⁶³-1

CVV2_Result

Used only if CVV2 is present in request. M=Match; N=No-match.

Any other values other than M and N will cause a format error rejection.

Note: If the CVV2_Result field is blank, then the merchant did not provide this information. In this case, Thredd will not complete the CVV2 pre-check and will authorise or decline the transaction based on the card usage group settings for your programme.

A(1,1)

AvlBalance_GPS_STIP

Similar to AvlBalance, this field is used in Gateway Processing with STIP (mode 4 only) to update the available Thredd stand-in balance. It will only be used to approve or decline EHI messages where a response from the External Host is not received and it will be decremented with every approval.
It is never sent back to the card network for any response message where the acquirer is expecting the card’s available balance, such as Balance Inquiry transactions. Instead, the AvlBalance field, if sent by the External Host, is used for this purpose.

AmountSigned (9,2)

CurBalance_GPS_STIP

Similar to CurBalance, this field is used in Gateway Processing with STIP (mode 4) to update the current Thredd stand-in balance.

AmountSigned (9,2)

0100

A

Authorisation Request

D

Automatic Authorisation Reversal

0101

A

Authorisation Repeat (Visa Only)

0120

J

Authorisation Advice

0120

D

Authorisation Reversal Advice (due to AFD Automatic fuel dispensers (AFDs) are used at petrol or gas stations for customer self-service fuel payments. Typically the customer inserts their card and enters a PIN number and the AFD authorises a fixed amount (e.g. £99). Once the final payment amount is known, the AFD may reverse the authorisation and/or request a second authorisation. 0120 auth advice)

0400

D

Authorisation Reversal Request

0420

D

Authorisation Reversal Advice

1240

05pp

06pp

07pp

(p = space)

A

Authorisation Advice Notification

(Dummy authorisation created if a Financial notification has no matching authorisation.)

1240

25pp

26pp

27pp

(p = space)

E

Financial Reversal

1240

C

Chargeback Notification

1240

H

Chargeback Notification (Non-Credit)

1240

K

Chargeback Reversal

1240

05pp

06pp

07pp

(p = space)

N

Financial Notification (Second Presentment)

1240

05pp

06pp

07pp

(p = space)

P

Financial Notification

(First Presentment)

L

Load

U

Unload

G

Payment

B

Balance Adjustment

Y

Card Expiry

0100

A

D

0101

A

0120

J

0400

D

Acquirer_id_DE32

Optional

VL_Group

Optional

Merch_Street

ActBal

Mandatory

Dom_Fee_Fixed

Mandatory

Merch_City

Additional_Amt_DE54

Optional

Non_Dom_Fee_Fixed

Mandatory

Merch_Region

Amt_Tran_Fee_DE28

Optional

Fx_Fee_Fixed

Mandatory

Merch_Postcode

Auth_Code_DE38

Optional

Other_Fee_Amt

Mandatory

Merch_Country

Avl_Bal

Mandatory

Fx_Fee_Rate

Mandatory

Merch_URL

Bill_Amt

Mandatory

Dom_Fee_Rate

Mandatory

Merch_Name_Other

Bill_Ccy

Mandatory

Non_Dom_Fee_Rate

Mandatory

Merch_Net_id

BlkAmt

Mandatory

Additional_Data_DE124

Optional

Merch_Tax_id

Cust_Ref

Optional

CVV2

Optional

Merch_Contact

FX_Pad

Mandatory

Expiry_Date

Optional

auth_type

Fee_Fixed

Mandatory

PAN_Sequence_Number

Optional

auth_expdate_utc

Fee_Rate

Mandatory

PIN

Optional

Matching_Txn_ID

LoadSRC

Optional

PIN_Enc_Algorithm

Optional

Reason_ID

LoadType

Optional

PIN_Format

Optional

Dispute_Condition

MCC_Code

Optional

PIN_Key_Index

Optional

Network_Chargeback_Reference_Id

MCC_Desc

Optional

SendingAttemptCount

Mandatory

Acquirer_Forwarder_ID

MCC_Pad

Mandatory

source_bank_ctry

Omitted

DCC_Indicator

Merch_ID_DE42

Optional

source_bank_account_format

Omitted

multi_part_txn

Merch_Name_DE43

Mandatory

source_bank_account

Omitted

multi_part_txn_final

Note

Optional

dest_bank_ctry

Omitted

multi_part_number

POS_Data_DE22

Optional

dest_bank_account_format

Omitted

multi_part_count

POS_Data_DE61

Optional

GPS_POS_Capability

Mandatory

SettlementIndicator

POS_Termnl_DE41

Optional

GPS_POS_Data

Optional

Clearing_Process_Date

POS_Time_DE12

Optional

Acquirer_Reference_Data_031

Omitted

Settlement_Date

Proc_Code

Mandatory

Response_Source

Optional

Currency_Code_Fee

Resp_Code_DE39

Depends on EHI mode:

Mode 1: Optional

Mode 2: Optional

Mode 3: Mandatory

Mode 4 : Optional

Response_Source_Why

Optional

Currency_Code_Fee_Settlement

Ret_Ref_No_DE37

Optional

Message_Source

Optional

Interchange_Amount_Fee

Settle_Amt

Optional

Message_Why

Optional

Interchange_Amount_Fee_Settlement

Settle_Ccy

Optional

traceid_lifecycle

Optional

Traceid_Message

Status_Code

Mandatory

Balance_Sequence

Optional

Traceid_Original

Token

Mandatory

Balance_Sequence_Exthost

Optional

Network_Transaction_ID

Trans_link

Mandatory

PaymentToken_id

Optional

POS_Date_DE13

Txn_Amt

Mandatory

PaymentToken_creator

Optional

Network_Currency_Conversion_Date

Txn_CCy

Mandatory

PaymentToken_expdate

Optional

Network_TxnAmt_To_BillAmt_Rate

Txn_Ctry

Optional

PaymentToken_type

Optional

Network_TxnAmt_To_BaseAmt_Rate

Txn_Desc

Optional

PaymentToken_status

Optional

Network_BaseAmt_To_BillAmt_Rate

Txn_GPS_Date

Mandatory

PaymentToken_creatorStatus

Optional

Network_Original_Data_Elements_DE90

TXn_ID

Mandatory

PaymentToken_wallet

Optional

Network_Replacement_Amounts_DE95

Txn_Stat_Code

Mandatory

PaymentToken_deviceType

Optional

Network_Issuer_Settle_ID

TXN_Time_DE07

Mandatory

PaymentToken_lang

Optional

Visa_ResponseInfo_DE44 Optional

Txn_Type

Mandatory

PaymentToken_deviceTelNum

Optional

Visa_POS_Data_DE60 Optional

Additional_Data_DE48

Optional

PaymentToken_deviceIp

Optional

Visa_STIP_Reason_Code Optional

Authorised_by_GPS

Optional

PaymentToken_deviceId

Optional

Mastercard_AdviceReasonCode_DE60 Optional

AVS_Result

Optional

PaymentToken_deviceName

Optional

Misc_TLV_Data

CU_Group

Optional

PaymentToken_activationCode

Optional

Network_Fraud_Data

InstCode

Mandatory

PaymentToken_activationExpiry

Optional

SenderData

MTID

Mandatory

PaymentToken_activationMethod

Optional

ReceiverData

ProductID

Mandatory

PaymentToken_PanSource

Optional

AuthenticationCurrency

Record_Data_DE120

Optional

PaymentToken_activationMethodData

Optional

AuthenticationAmountUpper

Acquirer_Country

Optional

ICC_System_Related_Data_DE55

Optional

AuthenticationMerchantHash

SubBIN

Mandatory

VL_Group

Optional

FxProviderCardholderRate

Responsestatus

CurBalance

AvlBalance

Acknowledgement

LoadAmount

Bill_Amt_Approved

Update_Balance

New_Balance_Sequence_Exthost

CVV2_Result

AvlBalance_GPS_STIP

CurBalance_GPS_STIP

1240

05pp

06pp

07pp

(p = space)

A

1240

C

1240

H

1240

K

1240

05pp

06pp

07pp

(p = space)

P

1240

25pp

26pp

27pp

(p = space)

E

1240

05pp

06pp

07pp

(p = space)

N

Acquirer_id_DE32

Optional

dest_bank_account_format

ActBal

Mandatory

dest_bank_account

Additional_Amt_DE54

Optional

GPS_POS_Capability

Amt_Tran_Fee_DE28

Optional

GPS_POS_Data

Auth_Code_DE38

Optional

Acquirer_Reference_Data_031

Avl_Bal

Mandatory

Response_Source

Bill_Amt

Mandatory

Response_Source_Why

Bill_Ccy

Mandatory

Message_Source

BlkAmt

Mandatory

Message_Why

Cust_Ref

Optional

traceid_lifecycle

FX_Pad

Mandatory

Balance_Sequence

Fee_Fixed

Mandatory

Balance_Sequence_Exthost

Fee_Rate

Mandatory

PaymentToken_id

LoadSRC

Optional

PaymentToken_creator

LoadType

Optional

PaymentToken_expdate

MCC_Code

Optional

PaymentToken_type

MCC_Desc

Optional

PaymentToken_status

MCC_Pad

Mandatory

PaymentToken_creatorStatus

Merch_ID_DE42

Optional

PaymentToken_wallet

Merch_Name_DE43

Mandatory

PaymentToken_deviceType

Note

Optional

PaymentToken_lang

POS_Data_DE22

Optional

PaymentToken_deviceTelNum

POS_Data_DE61

Optional

PaymentToken_deviceIp

POS_Termnl_DE41

Optional

PaymentToken_deviceId

POS_Time_DE12

Optional

PaymentToken_deviceName

Proc_Code

Mandatory

PaymentToken_activationCode

Resp_Code_DE39

Optional

PaymentToken_activationExpiry

Ret_Ref_No_DE37

Optional

PaymentToken_activationMethod

Settle_Amt

Optional

PaymentToken_activationMethodData

Settle_Ccy

Optional

ICC_System_Related_Data_DE55

Status_Code

Mandatory

Merch_Name

Token

Mandatory

Merch_Street

Trans_link

Mandatory

Merch_City

Txn_Amt

Mandatory

Merch_Region

Txn_CCy

Mandatory

Merch_Postcode

Txn_Ctry

Optional

Merch_Country

Txn_Desc

Optional

Merch_Tel

Txn_GPS_date

Mandatory

Merch_URL

TXn_ID

Mandatory

Merch_Name_Other

Txn_Stat_Code

Mandatory

Merch_Net_id

TXN_Time_DE07

Optional

Merch_Tax_id

Txn_Type

Mandatory

Merch_Contact

Additional_Data_DE48

Optional

Auth_Type

Authorised_by_GPS

Optional

auth_expdate_utc

AVS_Result

Optional

Matching_Txn_ID

CU_Group

Optional

Reason_ID

InstCode

Mandatory

Dispute_Condition

MTID

Mandatory

Network_Chargeback_Reference_Id

ProductID

Mandatory

Acquirer_Forwarder_ID

Record_Data_DE120

Omitted

DCC_Indicator

SubBIN

Mandatory

multi_part_txn

TLogIDOrg

Optional

multi_part_txn_final

VL_Group

Optional

multi_part_number

Dom_Fee_Fixed

Mandatory

multi_part_count

Non_Dom_Fee_Fixed

Mandatory

SettlementIndicator

Fx_Fee_Fixed

Mandatory

Clearing_Process_Date

Other_Fee_Amt

Mandatory

Settlement_Date

Fx_Fee_Rate

Mandatory

Currency_Code_Fee

Dom_Fee_Rate

Mandatory

Currency_Code_Fee_Settlement

Non_Dom_Fee_Rate

Mandatory

Interchange_Amount_Fee

Additional_Data_DE124

Optional

Interchange_Amount_Fee_Settlement

CVV2

Omitted

Traceid_Message

Expiry_Date

Optional

Traceid_Original

PAN_Sequence_Number

Optional

Network_Transaction_ID

PIN

Omitted

POS_Date_DE13

PIN_Enc_Algorithm

Omitted

Network_Currency_Conversion_Date

PIN_Format

Omitted

Network_TxnAmt_To_BillAmt_Rate

PIN_Key_Index

Omitted

Network_TxnAmt_To_BaseAmt_Rate

SendingAttemptCount

Mandatory

Network_BaseAmt_To_BillAmt_Rate

source_bank_ctry

Omitted

Network_Original_Data_Elements_DE90

source_bank_account_format

Omitted

Network_Replacement_Amounts_DE95

source_bank_account

Omitted

ReceiverData

ClearingFileId

Optional

FxProviderCardholderRate

Responsestatus

CurBalance

AvlBalance

Acknowledgement

LoadAmount

Bill_Amt_Approved

Update_Balance

New_Balance_Sequence_Exthost

CVV2_Result

AvlBalance_GPS_STIP

n/a (not present)

L

n/a (not present)

U

n/a (not present)

G

n/a (not present)

B

n/a (not present)

Y

n/a (not present)

P

Acquirer_id_DE32

Omitted

dest_bank_account

ActBal

Mandatory

GPS_POS_Capability

Additional_Amt_DE54

Omitted

GPS_POS_Data

Amt_Tran_Fee_DE28

Omitted

Acquirer_Reference_Data_031

Auth_Code_DE38

Omitted

Response_Source

Avl_Bal

Mandatory

Response_Source_Why

Bill_Amt

Mandatory

Message_Source

Bill_Ccy

Mandatory

Message_Why

BlkAmt

Mandatory

traceid_lifecycle

Cust_Ref

Optional

Balance_Sequence

FX_Pad

Mandatory

Balance_Sequence_Exthost

Fee_Fixed

Mandatory

PaymentToken_id

Fee_Rate

Mandatory

PaymentToken_creator

LoadSRC

Optional

PaymentToken_expdate

LoadType

Optional

PaymentToken_type

MCC_Code

Omitted

PaymentToken_status

MCC_Desc

Omitted

PaymentToken_creatorStatus

MCC_Pad

Omitted

PaymentToken_wallet

Merch_ID_DE42

Omitted

PaymentToken_deviceType

Merch_Name_DE43

Omitted

PaymentToken_lang

Note

Optional

PaymentToken_deviceTelNum

POS_Data_DE22

Omitted

PaymentToken_deviceIp

POS_Data_DE61

Omitted

PaymentToken_deviceId

POS_Termnl_DE41

Omitted

PaymentToken_deviceName

POS_Time_DE12

Omitted

PaymentToken_activationCode

Proc_Code

Mandatory

PaymentToken_activationExpiry

Resp_Code_DE39

Omitted

PaymentToken_activationMethod

Ret_Ref_No_DE37

Omitted

PaymentToken_activationMethodData

Settle_Amt

Optional

ICC_System_Related_Data_DE55

Settle_Ccy

Optional

Merch_Name

Status_Code

Mandatory

Merch_Street

Token

Mandatory

Merch_City

Trans_link

Mandatory

Merch_Region

Txn_Amt

Mandatory

Merch_Postcode

Txn_CCy

Mandatory

Merch_Country

Txn_Ctry

Optional

Merch_Tel

Txn_Desc

Optional

Merch_URL

Txn_GPS_Date

Mandatory

Merch_Name_Other

TXn_ID

Mandatory

Merch_Net_id

Txn_Stat_Code

Mandatory

Merch_Tax_id

TXN_Time_DE07

Omitted

Merch_Contact

Txn_Type

Mandatory

auth_type

Additional_Data_DE48

Omitted

auth_expdate_utc

Authorised_by_GPS

Omitted

Matching_Txn_ID

AVS_Result

Omitted

Reason_ID

CU_Group

Optional

Dispute_Condition

InstCode

Mandatory

Network_Chargeback_Reference_Id

MTID

Omitted

Acquirer_Forwarder_ID

ProductID

Mandatory

DCC_Indicator

Record_Data_DE120

Omitted

multi_part_txn

SubBIN

Mandatory

multi_part_txn_final

TLogIDOrg

Omitted

multi_part_number

VL_Group

Optional

multi_part_count

Dom_Fee_Fixed

Mandatory

SettlementIndicator

Non_Dom_Fee_Fixed

Mandatory

Clearing_Process_Date

Fx_Fee_Fixed

Mandatory

Settlement_Date

Other_Fee_Amt

Mandatory

Currency_Code_Fee

Fx_Fee_Rate

Mandatory

Currency_Code_Fee_Settlement

Dom_Fee_Rate

Mandatory

Interchange_Amount_Fee

Non_Dom_Fee_Rate

Mandatory

Interchange_Amount_Fee_Settlement

Additional_Data_DE124

Omitted

Traceid_Message

CVV2

Omitted

Traceid_Original

Expiry_Date

Omitted

Network_Transaction_ID

PAN_Sequence_Number

Omitted

POS_Date_DE13

PIN

Omitted

Network_Currency_Conversion_Date

PIN_Enc_Algorithm

Omitted

Network_TxnAmt_To_BillAmt_Rate

PIN_Format

Omitted

Network_TxnAmt_To_BaseAmt_Rate

PIN_Key_Index

Omitted

Network_BaseAmt_To_BillAmt_Rate

SendingAttemptCount

Mandatory

Network_Original_Data_Elements_DE90

source_bank_ctry

Optional

Network_Replacement_Amounts_DE95

source_bank_account_format

Optional

Network_Issuer_Settle_ID

source_bank_account

Optional

Visa_ResponseInfo_DE44

dest_bank_ctry

Optional

Visa_POS_Data_DE60

Responsestatus

CurBalance

AvlBalance

Acknowledgement

LoadAmount

Bill_Amt_Approved

Update_Balance

New_Balance_Sequence_Exthost

CVV2_Result

AvlBalance_GPS_STIP