Payment Processing Technical FAQs

An Account Status Inquiry (ASI) 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).

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.

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.

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. ).

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?

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?.

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 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 the client is seeing a discrepancy with the balance in the XML file and in Thredd Portal or Smart Client.