Payment Processing Technical FAQs

This depends on your EHI mode and the type of transaction. Refer to the table below for common use case examples:

Since Responsestatus is a mandatory field in authorisation messages, a value must always be returned, even if only responding to an authorisation advice. For authorisation advices, Thredd ignores the value provided in this field.

The default EHI authorisation response timeout is set to account for the full round-trip time, including processing and routing, between Thredd and your external host. This time includes all parties and systems involved in the transaction, each taking a portion of the available time.

Yes, the timeout can be extended, but any permanent higher timeouts may be chargeable. If you are considering this, it is recommended to consult with your Thredd Implementation Manager for further details and to ensure it aligns with your program's requirements.

Only relevant to processing modes where your systems return an authorisation response to Thredd (EHI Gateway Processing and Cooperative Processing).

For more information, see the EHI Guide: Troubleshooting FAQs and the EHI Guide: Configuration Options.

This depends on your EHI Mode configuration:

• In processing modes where your systems return an authorisation response to Thredd (EHI Gateway Processing and Cooperative Processing), the transaction will be declined automatically if no response is received within the timeout period. Thredd then resends the transaction to notify you of the decision made.

• If the Thredd platform is configured to provide Stand-in Processing (STIP), then Thredd makes a stand-in processing decision, which could be Approve or Decline. Thredd then resends the transaction to notify you of the decision made.

• In full Service Processing, Thredd handles the authorisation and sends you an advice. Your systems need to respond with an acknowledgement. If your acknowledgement is not received, Thredd will resend the advice, up to the maximum number of times configured for your program.

For more information on responding to EHI messages, see the EHI Guide: Processing EHI Transactions.

For more information on EHI modes, see the EHI Guide: Processing EHI Operating Modes.

No, Thredd will either decline the transaction (if you are using Gateway Processing mode) or manage the authorisation decision (if you are using Cooperative Processing or Gateway Processing with STIP modes). See Q. What happens if our systems do not return a response to EHI within the permitted timeout period?

Only relevant to processing modes where your systems return an authorisation response to Thredd (EHI Gateway Processing and Cooperative Processing).

After you respond to the original EHI message with an approve or decline, you can have one of the following outcomes:

• Scenario 1: your systems respond, but the transactions times out before Thredd receives the response (response not received within the allowed timeout period):

  • Thredd will decline the transaction.

    - Or -

  • If Thredd Gateway Stand-In Processing (STIP) is enabled, you will receive an 0100A message with 'Authorised_by_GPS'=Y, TxnStatCode=I.

• Scenario 2: your systems respond, Thredd receives the response, but the transaction times out before reaching the Card Scheme:

  • You will receive an 0120J message stating the transaction was declined.

• Scenario 3: your systems respond, Thredd receives the response, which is passed successfully to the Card Scheme:

  • You will not receive any subsequent EHI message. There is no final status response from Thredd.

For more information on responding to EHI messages, see the EHI Guide: Processing EHI Transactions.

For more information on EHI modes, see the EHI Guide: Processing EHI Operating Modes.

You can use the List Card Transactions REST API to view details of the transaction status for all transactions linked to a card over a specified time period.

If using SOAP web services, then the Card Statement web service provides similar functionality.

Alternatively, your call centre staff can check the status of any card transaction using Thredd Portal or Smart Client.

If your systems are managing the authorisation process (EHI Gateway and Cooperative processing modes), then you can identify an ASI transaction by the following: MTID=100 and Bill_Amt=0 and auth_type = V. You can respond using proc_code= 39 to indicate this is an ASI transaction.

An Account Status Inquiry (ASI) or Account Verification transaction is a message type that enables a merchant to check the Card Validation Code (CVC) and, if address details are provided, to optionally use the Address Verification Service (AVS).

If the ASI checks are successful, Thredd responds with an 00 approval to the merchant. The merchant then typically submits a second transaction with an actual transaction amount included. For more information, see Account Status Inquiry (ASI).

If enabled for your programme, Thredd carries out any AVS service address verification checks on the transaction requested by the Merchant. Thredd provides the result in the AVS_Result field of the authorisation request, and this result will be returned to the merchant in the authorisation response.

In processing modes where your systems return an authorisation response to Thredd (EHI Gateway Processing and Cooperative Processing):

• If you decline the transaction due to the AVS result, the decline response is final.

• If you respond with an approval, the merchant still has the final decision whether to approve or decline the transaction due to AVS validation failure.

For more information, see Address Verification Service (AVS).

The Card Verification Value (CVV) is a critical security feature used to verify that the cardholder has physical possession of the card during a transaction, especially for card-not-present (e-commerce) transactions. If CVV checks fail, the transaction is typically declined.

Further details

1. If the CVV provided by the cardholder does not match the value on record, then Thredd declines the transaction.

2. Thredd will send you an EHI 0100A message with Authorised_by_GPS=Y, TxnStatCode=I, and Note= DR: Emboss CVC2 not matching with CVC2. A specific response code, such as 6P (Verification Data Failed), may be returned in the Resp_Code_DE39 field to indicate that the provided verification data (e.g., CVV) is invalid or missing.

3. After the cardholder exceeds the maximum number of CVV tries permitted for your programme, Thredd will block the CVV and send you an EHI message with Authorised_by_GPS=Y, TxnStatCode=I, and Note=DR: CVC2 tries exceeded.

For large merchants, CVV checks may not always be enforced. If a CVV response is mandatory and the merchant does not send the CVV, this could also result in a decline. To avoid unnecessary declines, it is recommended to set the Allow Blank CVV2 in Card Not Present E-commerce option to Yes in your card usage rules. For more information, see the EHI Guide: Dynamic CVV2.

If you are using Dynamic CVV2, ensure that the system is configured to validate the dynamic CVV2 value correctly. Failure to do so may also result in declines. For more information, see the EHI Guide: Dynamic CVV2.

The maximum number of CVV tries allowed for a card on your programme is defined on your Product Setup Form (PSF). After exceeding the maximum number of tries, the CVV is blocked.

You can unblock the CVV using Thredd Portal, Smart Client or the Thredd API:

• If using the REST API, see Card Verification Value (CVV2).

• If using SOAP web services, see Card PIN Control.

No, the CVV block does not have any impact on refund or reversal transactions as the CVV is not sent in these transactions. Other types of financial messages are also not affected.

No, the CVV block will not change the card status.

A Money Send transaction is a type of fund transfer transaction typically used for transferring funds directly to a cardholder's account. Unlike refunds, Money Send transactions are not linked to a previous transaction. Examples include Visa Fast Funds and Mastercard Money Send. Money Send transactions must be funded to the target card within 30 minutes of authorisation.

How to identify

• A Money Send transaction is sent via EHI as an 0100A message, with Proc_code=28.

How to respond

• Approve the transaction if it meets the required criteria and the funds are available.

• Ensure the response includes <Responsestatus>00</Responsestatus> and <Acknowledgement>1</Acknowledgement> to confirm approval and receipt of the message.

• Credit the funds to the target card within the stipulated 30-minute window.

• Monitor for duplicate credits to avoid errors when financial messages are received. (Money Send will have a presentment transactions of 1240P with proc_code=28xxxx).

Check with your Visa or Mastercard representative to confirm the funding requirements specific to your region or country.

How to disable

You can set up card usage to decline Money Send transactions by disabling the Instant funding parameter on your Product Setup Form (PSF).

You can identify an incremental authorisation as follows:

• txn_type = A (authorisation)

• In Message_Why, the Response_Why value = 56 (for Visa) and will be blank for Mastercard.

• auth_type = 0 or P (used for both preauths and incremental auths)

• The following fields will be the same as in the original authorisation: Token, Txn_CCy and traceid_lifecycle

• The Network_Transaction_ID field will be unique.

Other ways you can use to identify incremental authorisations:

• For Mastercard, you can use the Traceid_Original field. Positions 1-9 will have the same value as the original authorisation.

• For Visa, Reason_ID = 3900 (incremental auth for Visa).

  In some instances, this field may be blank, so you should not rely on it.

For more information, see the EHI Guide FAQs: Q. What is an incremental authorisation and how do I identify it?

You can identify a final authorisation when auth_type=F. This indicates that the transaction is the final transaction message in a multi-part incremental authorisation sequence. Previous authorisation transactions have auth_type=0. Incremental authorisations are used to request an additional amount for the same product or service purchased by the cardholder (usual cases: hotels, car rentals).

See the example below. Assume the starting blocked amount on the card is zero.

You can match incremental authorisations using the traceid_lifecycle value. The final amount = sum of all approved transaction amounts - sum of all reversed transaction amounts (if any). For more information see the Incremental Authorisations section in the EHI Guide: Transaction Flow Scenarios.

Yes, if the transaction is done in a currency that is not the settlement currency, it is possible for the Bill_Amt to be different between Authorisation, Presentment and Refund, due to exchange rate fluctuations.

How this works

• When a transaction occurs in a foreign currency, the authorisation amount is initially locked based on the exchange rate at the time of authorisation.

• However, by the time the transaction settles, the exchange rate may have changed.

• The Card Scheme (e.g. Visa or Mastercard) applies the exchange rate at the time of settlement if it is unable to apply the rate used at authorisation. This can cause the settlement amount (the amount the issuer actually settles for) to differ from the originally authorised amount.

• Additionally, dynamic currency conversion (DCC) or merchant-applied currency conversions at point of sale can cause amounts to differ from the Card Scheme's own rates.

Mastercard's rules specify that the settlement amount uses Mastercard's exchange rate at settlement time rather than the authorisation exchange rate if the latter is unavailable. The exchange rate from Mastercard is given in the Network_TxnAmt_To_BillAmt_Rate field.

An offline transaction is a type of payment transaction where the merchant terminal does not request authorisation from the card issuer in real-time. Instead, the transaction is approved or declined based on the card's CHIP EMV settings, which determine whether offline transactions are permitted. This is commonly used in scenarios such as low-risk, small-value transactions (e.g., public transport or airlines).

For more information see the EHI Guide FAQs: Q. What is an offline transaction and how do I handle it?.

This depends on the type of authorisation request:

• For Authorisations, if Thredd does not receive a matching presentment within 7 days of the Authorisation, we will send the automatic Authorisation reversal (MTID -, Txn_type=D) just after midnight UK time after 8 days.

• For Pre-authorisations, if Thredd does not receive any matching presentment within 30 days of the Authorisation, we will send the automatic Authorisation reversal (MTID -, Txn_type=D) just after midnight UK time after 31 days.

  If you have set up a hanging filter The period of time during which waits for an approved authorisation amount to be settled. This is defined at a product level. A typical default is 7 days for an auth and 10 days for a pre-auth. for authorisations on your account, then the authorisation will expire after the hanging filter period.

If Thredd detects that a presentment is received without an earlier matching authorisation, Thredd creates and sends the 1240A message. You will receive:

• 1240A (dummy authorisation)

• 1240P Presentment

For more information, see 'First presentment for an offline transaction' in the EHI Guide: Transaction Flow Scenarios.

Refunds

If a transaction is already cleared and the merchant sends a refund, the flow is:

1. 0100A Auth message received and transaction is approved.

2. 1240P First presentment received.

3. 1240E Refund message received.

4. How to respond: Your systems acknowledge (all EHI modes) and respond with an approve or decline (Gateway and Cooperative Processing only).

Some merchants send refunds as MTID=1240P (with proc_code= 20xxxx). In this case, a refund is a presentment advice and not an online transaction requiring approval. This means you cannot reject the refund.

A refund sent as MTID=0120 (with proc_code= 20xxxx) occurs where the network is Standing In on behalf of the issuer (such as in situations like issuer timeouts or network transaction blocking).

Reversals

If a transaction is not yet cleared and the merchant sends a reversal, the flow is:

1. 0100A Auth message received and transaction is approved.

2. 0400 D Auth Reversal message received.

3. How to respond: Your systems acknowledge (all EHI modes) and respond with an approve or decline (Gateway and Cooperative Processing only).

A credit adjustment is a correction made to the account balance. For example, if there was a refund related to a purchase, it will increase the card balance to reflect the correct amount. Credit adjustments are processed as an 0100A authorisation request with proc_code=02.

The Business Application Identifier (BAI) in Visa Direct Original Credit Transaction (OCT) Field 104, Dataset ID 57, is a code used to identify the category or type of Visa Money Transfer being conducted through the OCT.

Thredd processes the Business Application Identifier field on behalf of clients and does not pass it onto any clients via EHI.

ATM withdrawals using the magnetic stripe are hard-coded to be declined by Thredd due to the high risk nature of this input method. (A skimmer can copy the magnetic stripe and write it to a blank card, which is then used to get cash out of an ATM.)

You can instruct the cardholder to go to an ATM that uses Chip and PIN as the entry mode.

How to Identify Magnetic Stripe usage on ATMs

• If the Transaction Type is 01 and the Terminal PAN Entry Mode is one of 02, 80 (except for Visa) or 90, then this is an ATM magnetic stripe attempt.

This may happen in a number of fields, depending on the field:

• The assigned data type supports more characters than have been entered. For example, the field has 14 digits, but only 10 are used.

• The Acquirer may submit records with blank spaces in some fields.

Thredd occasionally receives data from the Card Scheme or Acquirer that contains fields populated with unrecognised hexadecimal characters. During conversion in External Host Interface (EHI) to the JSON format, data is encoded according to the JSON specification. Where the converter does not recognise a character, a character substitution is made in the field, based on the conversion standard.

For more information, see EHI Guide Troubleshooting FAQs: Q. How to handle processing errors due to invalid characters?.

The Desc field maximum value is 500 characters.

The MerchantAdvice in the authorisation response is a string with possible numbers 01, 02 and 03. For more information, see Response Fields in JSON Data Types and EHI Fields.

Yes, Proc_code is a mandatory field, so you will always receive it. You should use this field to identify the type of transaction. For example:

• 00 — Debits (goods and services)

• 01 — Debits for ATM cash withdrawals

• 02 — Indicates a Credit adjustment.

• 09 — Debits (goods with cash back)

For more information, see the EHI Guide: Processing Codes.

You can use the processing code to apply processing rules to the transaction (e.g. to restrict card usage or charge fees based on the type of transaction). For more information see the Fees Guide and the Physical Card Configuration Guide.

For refunds, merchants typically send a Financial Reversal (1240E) message with processing code 00xxxx or a Financial Notification (1240P or 066p) message with processing code 20xxxx.

for refunds, the Message Type Identifier (MTID) could be one of the following: 0100A, 0100D, 0120J 1240E, 1240P. Transactions must be matched at the MTID level rather than based on the processing code.

For more information, see the EHI Guide: Transaction Matching.

Applicable to transactions on Mastercard networks only.

DE 48 (Additional Data: Private Use) is reserved for private organisations to define data unique to specific networks or specific programs and services. DE 48 provides other supplemental data in a message when a specific ISO-designated data element is not available. It is a free-format, variable-length data element that may be used for multiple purposes.

Mastercard may occasionally introduce new DE 48 subelements and subfields between releases to facilitate special processing within a country, region, or among pilot participants. This data element’s content may vary by program and service.

For more information on possible field values and how to decode, refer to the Mastercard Customer Interface specifications. Thredd sends this field exactly as Mastercard sends it to us.

You can view decoded DE 48 information in Thredd Portal or Smart Client. See the Thredd Portal Guide: Viewing Transactions or the Smart Client Guide: Viewing Transaction details.

The Txn_Type field describes different types of transactions in the Thredd system. For example:

• L - Load: Represents a load transaction, where funds are added to the card or account. Example: Adding money to a prepaid card.

• U - Unload: Represents an unload transaction, where funds are removed from the card or account. Example: Withdrawing funds from a prepaid card.

• G - Payment: Represents a payment transaction, where funds are used to pay for goods or services. Example: A purchase at a store or online.

• B - Balance Adjustment: Represents a balance adjustment. Example: Adjusting the card balance due to an error or expiring unused funds.

• Y - Card Expiry: Represents a transaction related to card expiry. Example: Expiring a card and adjusting the balance accordingly.

• F - Fee: Represents a fee transaction, where a fee is charged to the card or account. Example: Charging a monthly maintenance fee or a transaction fee.

These transaction types are used in various contexts, such as reporting, processing, and matching transactions. Each type has specific rules and impacts on the card balance, depending on the configuration. For more information, see the EHI Guide: GetTransaction Message Fields.

PaymentToken_PanSource is a string that accepts the values specified in Payment Token Fields.

The Response_Source field contains a value in certain instances of Authorisation advices and Authorisation reversals. This typically occurs when the Network is standing-in on behalf of Thredd or during an AFD (Automated Fuel Dispenser) reversal process initiated by Thredd.

In the event of Issuer timeouts, if Thredd fails to respond promptly to the Network, and if Stand-in Processing (STIP) is set up at the network level for your card programme, then Mastercard or Visa will take action to approve or decline the transaction. If Mastercard or Visa has intervened and provided a response to the terminal, any corresponding Authorisation advice or Authorisation reversal will indicate Mastercard/Visa Stand-in as the Response source.

In the External Host Interface (EHI) message, you can use the GPS_POS_Data field to identify details of the transaction origination, such as if this is an e-commerce transaction (cardholder not present) or a Point of Sale Transaction (Card Present), as well has how the card data was entered and authenticated (e.g., contactless, Chip & Pin). For more information, see the External Host Interface Guide: GPS_POS_Data field.

You can use the Transaction Details screens in Thredd Portal or Smart Client to view information on the transaction origination and card acceptance method. (Click image to enlarge)

Figure: Transaction Details screen on Thredd Portal

For more information, see the Thredd Portal Guide or Smart Client Guide.

MCC_Pad is a feature that enables you to add a fixed percentage to each transaction for certain Merchant Category Codes (MCCs). Thredd includes this value as part of the calculation of the total cost of a payment transaction. For more information, see the EHI Guide: Calculating the Total Transaction Cost.

This value is sent in the MCC_Pad field in the External Host Interface (EHI) message.

This feature must be set up for your programme (you can specify the MCC_Pad percentage on your Product Setup Form (PSF) The Product Setup Form is a spreadsheet that provides details of your Thredd account setup. The details are used to configure your Thredd account. ).

• SettlementDate: The date when a transaction is considered settled — meaning the funds have been moved between the relevant parties (such as acquirer, issuer and cardholder accounts). It is used for matching settlement files, calculating fees, and resolving disputes.

• SchemeSettlementDate: The SchemeSettlementDate element describes the scheme first presentment settlement date in a financial advice or reversal. The data contained in this element is taken from data sources received from the Card Scheme.

• Reconciliation date: The business date on which a clearing record was entered in the Card Scheme's Clearing Management System.

  A Reconciliation Date can span one (or more) Calendar Dates.

Settle_Ccy is the settlement currency sent by the Card Scheme in the transaction.

Yes the sub-BIN will be displayed in the SubBIN EHI field.

The Cust_Ref field in EHI is a unique customer reference, which is retrieved from the CustomerReference field submitted in a Create card API request or CustAccount field sent using web services. If you are populating this field in your create card requests, then you can use the unique customer reference to match the transaction to a specific customer.

This is a replacement amount from the card network, which is used in reversals and completion advices to advise of the new amounts. It is received only if the reversal is partial. Otherwise, it is blank. For more information, see the EHI Guide: GetTransaction Message Fields.

Currently applicable to Visa network transactions only. For Mastercard the reversal amount is stated in the Bill_Amt field.

Yes, EHI is designed to support Mastercard DE48 subelements, including subelement 83, for communicating merchant advice codes. In the case of closed or cancelled cards, Thredd responds with the Merchant Advice Code (MAC) of "03" to instruct merchants not to retry.

For more information, see the Card Status and Response Codes Guide: EHI Response Codes: EHI Field MerchantAdvice.

The answer depends on your EHI mode:

• For EHI mode 1 (Gateway Processing), where you control the authorisation decision and maintain the card balance, you do not need to return the balance or update the balance on the card record.

• For EHI mode 3 (Full Service Processing), where Thredd controls the authorisation decision, Thredd provides you with an authorisation advice and you do not need to return the balance. You can use the Thredd API (web services or REST API) to maintain the balance recorded on the card.

• For EHI modes where you control the balance, but Thredd can provide the authorisation decision (Cooperative Processing and Gateway Processing with STIP), you must return the card balance. You can use the Thredd API (web services or REST API) to maintain the balance recorded on the card.

For more information, see the EHI Guide: EHI Operating Modes.

If you do not need to return the balance, then specify 0 for the balance fields in the EHI message.

Yes, in an incremental authorisation the final authorised amount can be different from the final settlement amount.

How to handle amounts in the final auth

• When you receive a final authorisation, if approved then revise the amount blocked on the card based on the final amount. This is typically the amount expected to be settled.

How to handle amounts in the presentment

• When you receive a Settlement (Presentment), the final presentment amount may be different to the authorised amount. Common reasons for discrepancies include:

  • Currency exchange rate fluctuations (the authorisation transaction was in a different currency to the default settlement currency).

  • Additional charges like tips or service fees.

  • Merchant errors or adjustments.

• Upon receiving the presentment, you must unblock the amount that was blocked during the authorisation process.

When you receive an incremental presentment, unblock only the amount stated and not the full amount previously authorised. The amount to be billed to customer will be Bill_Amt.

When you have received the final presentment, you can calculate the total and unblock any amount left on the original authorisation.

How to identify whether a transaction is a single or multi-part presentment:

1. For a single presentment, both the values of multi_part_txn and multi_part_txn_final will be 0.

2. If a presentment is a part of multi-clearing, either the multi_part_txn will have value of 1 (any part of multi-clearing) or multi_part_txn_final will have value of 1 (final part of multi-clearing).

Yes, if the transaction is done in a currency that is not the settlement currency, then the Bill_Amt may be different between Authorisation, Presentment and Refund transactions, due to the exchange rate fluctuations.

The exchange rate from Mastercard is provided in the Network_TxnAmt_To_BillAmt_Rate field.

If the transaction currency is different from the billing currency, a foreign exchange fee (FX Fee) is applied. Depending on your configuration, FX Fees could be applied to both a presentment and a refund. Also, if the exchange rate changed between the presentment and refund, this could cause a further difference between the Refund Authorisation and Presentment amounts.

Yes, the fees are distributed proportionally between split financials (both for Visa and Mastercard). See the example below, where the interchange fee is split across three partial amount presentments:

These are EHI messages generated based on batch clearing files received from card schemes. They include various transaction types such as presentments, chargebacks and chargeback reversals. These messages require acknowledgement only.

A financial reversal occurs when the Merchant or Acquirer cancels all or part of a prior transaction (which may be a purchase, refund, cashback, cash, PIN change, or any other transaction type). This type of message is sent after the transaction has settled (the linked presentment has already been received). For example, if the Acquirer has already taken the funds and is aware of a processing error (e.g., double charging). You must return any deducted amounts back to the card.

A financial reversal is typically sent as an 1240 E (Financial Reversal) message. Some credit/refund transactions may be reported as MTID ‘1240’, Txn_type 'P' (with processing code 20xxxx).

The sending of these message types depends on whether the linked presentment has already been submitted or not:

• Authorisation Reversal — is sent before the transaction has settled (the linked presentment has not yet been submitted).

• Financial Reversal — is sent after the transaction has settled (the linked presentment has already been received).

You can use the Thredd Card Transaction System (CTS) to run test financial reversals. See Standard tests > Reversals. For more information, see the Card Transaction System (CTS) Guide.

A multi-part incremental presentment occurs when a merchant requests an authorisation for a specific amount but submits multiple presentments for different partial amounts (for example, a hotel billing a customer for multiple services, such as minibar, laundry etc). This type of transaction involves one authorisation and multiple presentment files. The final presentment total usually equals the total of the originally authorised amount.

You can identify an incremental presentment in a GetTransaction financial message if the multi_part_txn or multi_part_txn_final field is set to 1.

Additional fields provide details about the sequence and number of expected partial presentments:

• multi_part_txn_final

• multi_part_number

• multi_part_count (specific to Visa).

Unblocking Amounts:

When you receive an incremental presentment, only unblock the amount stated in the presentment, not the full amount previously authorised.

Once the final presentment is received, calculate the total and unblock any remaining amount.

For more information, see EHI Guide: FAQs.

A first presentment occurs when the merchant sends a request to take either part or all of the amount previously authorised on the card. This can happen at the same time as the authorisation request or in some cases it can be much later. You should attempt to match the presentment to the original authorisation request.

In a second presentment, the Issuer first raises a chargeback, the chargeback notification 1240H is first sent. Subsequently if the Merchant disputes the chargeback and provides more information (i.e. proof of the amount, an invoice, customer signature, shipping documents or the shipping address (used in AVS during the authorisation) then a second presentment (1240H) is issued by the acquirer usually within 45 calendar days of the Central Site Business Date.

The second presentment is thus the merchant resending the presentment to bill the cardholder, since the original presentment was refunded. For more information see the Chargebacks section in the EHI Guide: Transaction Flow Scenarios.

In summary:

The First Presentment: comes after the initial transaction vs Second Presentment: comes after the merchant’s attempt to fight a chargeback.

To raise a chargeback, follow these steps:

1. Eligibility for Chargeback:

Ensure the chargeback is for a legitimate reason, such as:

• Goods or services not received.

• Faulty goods.

• Fraudulent transactions.

2. Initiating the Chargeback:

• The cardholder must first attempt to resolve the issue directly with the merchant.

• If unresolved, the cardholder can raise a chargeback with their card issuer or Program Manager.

3. Using Thredd or Scheme Tools:

• You can create a chargeback using either the Visa or Mastercard online Dispute Management portals.

• Alternatively, you can use the Thredd Smart Client, which is Thredd's legacy desktop application for managing cards and transactions, to raise a Mastercard dispute.

4. Chargeback Process:

• The Program Manager or card issuer creates the chargeback request and sends it to the card scheme (e.g., Visa or Mastercard).

• Thredd receives a chargeback notification from the card scheme and forwards it to the external host (Program Manager).

• The Program Manager acknowledges the notification.

5. Merchant Response:

• If the merchant or acquirer accepts the chargeback, no further action is required.

• If the merchant or acquirer disputes the chargeback, a second presentment notification is sent to Thredd, which is then forwarded to the Program Manager for further action.

For more detailed guidance, refer to the Payments Dispute Management Guide.

For first presentments, (i.e., MTID = ‘1240’, ’05pp’, ’06pp’ or ‘07pp’ AND Txn_Type=’P’) 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.

Yes, the chargeback messages you can possibly receive via EHI message are:

1240 H (chargeback notification)

1240 K (chargeback reversal)

Note you will not receive 1240 C.

Yes, this relates only to chargeback messages.

To run test transactions in the UAT (User Acceptance Testing) environment, you can use the Thredd Card Transaction System (CTS). This system is specifically designed to help you test and validate your card processing systems before moving into a production environment.

For more information, see the Card Transaction System (CTS) Guide.

You can test a variety of transaction types. For example: POS, ATM, E-commerce, MOTO, Refund, Reversal, AFD (Automated Fuel Dispenser) and STIP (Stand-In Processing) transactions.

For more information, see the Card Transaction System (CTS) Guide.

The traceid_lifecycle and transaction_link fields in the EHI (External Host Interface) are critical for transaction matching, as they help link related transactions across their lifecycle.

• traceid_lifecycle is a unique identifier assigned to the lifecycle of a transaction. It remains consistent across all messages related to the same transaction, such as authorisation, incremental authorisation, authorisation reversal, financial presentment, chargeback, and second presentment. It is the primary field for transaction matching. If present, it should always be used first to match related transactions.

• transaction_link is used to link related transactions, such as an authorisation and its subsequent financial presentment or reversal. It is particularly useful as a fallback matching option when the traceid_lifecycle is not available.

If neither traceid_lifecycle nor transaction_link is present, you can try matching using other fields like:

• Auth_Code_DE38 (approval code)

• Merch_ID_DE42 (merchant ID)

• Acquirer_Reference_Data_031

The traceid_lifecycle is typically always present if an authorisation exists, making it the preferred field for matching.
If neither traceid_lifecycle nor transaction_link is present, it may not be possible to match the transaction.

You can use either Txn_GPS_Date or TXN_Time_DE07 to capture the time a transaction happens from the authorisation request fields received, as they contain both the date and time of Authorisation.

For more information, see GetTransaction Message Fields (XML) and GetTransaction Message Fields (JSON).

Yes. The ReasonCode field in the CardFinancial record can be blank. For more information on Reason Codes, see the Transaction XML Reporting Guide: Message Reason Codes.

The difference is usually caused by linked secondary cards. If a primary token shares the balance with secondary tokens, then the Balance XML Report shows the balance of the primary token and all of its secondary tokens together. But in Thredd Portal Thredd Portal is Thredd's new web application for managing your cards and transactions on the Thredd Platform. or Smart Client Smart Client is Thredd's legacy desktop application for managing your account on the Thredd Platform., a token’s balance is its own balance, and won’t show or sum up its secondary card’s balance. This is the reason why you are seeing a discrepancy with the balance in the XML file and in Thredd Portal or Smart Client.