Vantiv Tandem Auth Retail Transaction UML

Vantiv Tandem specific low-level representation of Retail Transaction produced by Forward Transformation Process within Authorization Process.
During Generation Process, Vantiv Tandem specific interchange message is generated from this object for authorization. Consequently, all fields of the object are mapped into message segments/elements.

Approved amount of the transaction.

Indicator of the result of the transaction that requested authentication.

Used in conjunction with the Message Type Identifier to determine which data elements are in the message being transmitted.

Primary Account Number.

The PAN field must appear in the following message type:

0400 Reversal request

The field can contain up to 19 bytes of alphanumeric data representing the debit or credit card number associated with the transaction being reversed (voided). The data is left justified, space filled. This field can contain the encrypted PAN when the POS is using a supported encryption vendor’s software.

When transaction using token (POS condition code position 8 = 5 with group request data G028) must set this field to spaces for applicable base request messages.

Processing Code.

May appear in the following message types:

• 0100 and 0110 - Authorization request and response
• 0200 and 0210 - Financial request and response
• 0220 and 0230 - Financial request and response
• 0400 - Unsolicited Reversal request (this is the Processing code of the original that is being reversed. The original processing code was ISO Format. This code will be its equivalent value in TPS format.)
• 0410 - Reversal response
• 0500 - Reconciliation request

Consists of three two-digit sub fields that indicate how the transaction specified by the message type affects the customer’s related account(s).

Note: The authorization service can update the "From" and "To" account information. The operating rules for the authorization service may require the terminal device to print the account information on the receipt.

Transaction Amount.

This field may appear in the following message types:

• 0100 Authorization request
• 0110 Authorization response
• 0200 Financial request
• 0220 Financial request
• 0400 Unsolicited Reversal Request

The nine-digit transaction amount field represents the monetary value associated with the cardholder’s authorization, debit, or credit transaction request. The amount is entered in the terminal as a seven-digit number and is always right justified and zero filled. This field does not include cash back.

• For authorization reversals this field must contain the approved amount authorized from the original transaction.
• For timeout scenarios where the approved amount is not known, populate this field with the original amount requested in the timed-out transaction.
• For AVS verification only (Processing code 514000) request, this field must be zero filled.
• For MasterCard and Discover Account Status Inquiry transactions this field must be zero-filled.
• For Visa Product Eligibility Inquiry transactions this field must be zero-filled.
• For EBT WIC purchases, this represents the amount of the transaction BEFORE any coupons or discounts are applied.

Amount.

This field may appear in the following message types:

• 0100 Authorization request
• 0110 Authorization response
• 0200 Financial request
• 0220 Financial request
• 0400 Unsolicited Reversal Request

The nine-digit transaction amount field represents the monetary value associated with the cardholder’s authorization, debit, or credit transaction request. The amount is entered in the terminal as a seven-digit number and is always right justified and zero filled. This field does not include cash back.

Transmission Date and Time.

The transmission date and time field may appear in the following message types:

• 0100 Check and financial authorization request (controller)
• 0100 Partial reversal
• 0110 Authorization response
• 0200 Financial request (controller)
• 0210 Financial response
• 0220 Credit card prior authorization
• 0400 Reversal (void) request (controller)
• 0410 Reversal (void) response

In the host capture terminal messages this field represents the date and time that the transaction was processed by the host.
In the host capture controller messages this is the date/time at which the controller transmitted the transaction to the Tandem Online System. It is set by the controller.
In a 0400 reversal message, the date and time apply to the reversal/void request itself, not the original transaction.

The ten-digit field is in MMDDYYhhmm format, with the time portion expressed in 24-hour (military) notation. For example, 1114971346 represents Nov. 14, 1997, at 1:46 P.M.

Contains several fields:

• Additional Response Data/CVV2/AVS Result Code;
• Payment Service Indicator;
• Transaction Identifier Banknet/POSA SAF Ref. Num.;
• VISA Validation Code.

Refer to the specification of the processor for more information.

AVS Result Code.

The field contains the CVV2 and address verification (AVS) result codes. Used for transactions where CVV2 and/or AVS was requested, it provides an additional indication that the card is being used by the person to which it was issued.

The first character is the CVV2 result code, the second character is the AVS result code (space when the transaction does not qualify for AVS). Visa and MasterCard return CVV2/CVC2 response codes. The following tables list the CVV2 and AVS result codes.

AVS RESULT CODE (POSITION 2)

• A - Address Matches, ZIP does not
• E - Error
• G - International issuer not participating in AVS
• N - Neither address nor ZIP matches
• R - Retry, system unavailable or timed out
• U - Issuer is unavailable
• Y - Address and ZIP both match
• Z - ZIP matches, address does not

Payment Service Indicator.

This single-character field must appear in the following message types:

• 0100 EFT partial reversal request
• 0110 Authorization response
• 0220 Financial request (Bit Map Type 04, 24)
• 0210 Financial response
• 0230 Financial response
• 0410 Reversal response

For VISA, the field contains a code that indicates whether the authorization qualifies for PS 2000 processing. ‘N’ = not PS2000 qualified; other values are as documented by VISA.
For MasterCard, the field contains a CVC (card validation character) compliance flag, used internally by the Tandem Online System.

Transaction Identifier Banknet/POSA SAF Ref. Num.

(VISA)/Banknet Data (MC)/POSA SAF Reference Number This 15-character field must appear in the following message types:

• 0100 EFT partial reversal request
• 0110 Authorization response
• 0220 Financial request (Bit Map Type 04, 24)
• 0210 Financial response
• 0230 Financial response
• 0410 Reversal response

The field will contain information provided by the authorizer.

• For VISA CPS implementation, it is a unique identifier used to link together all related transactions authorized and cleared through VISANet. If the Payment Service Indicator (bit 105.2) is ‘A’ and this field is not all zeros, it may be printed on receipts to facilitate retrieval requests but is not required. The printing of the Transaction ID is required for e-Сommerce Transaction Receipts.
• For POSA Prepaid, the field contains the POSA SAF Reference Number uniquely assigned by the host. This value occupies the first twelve positions left-justified space filled. The POS device should use this value to populate POSA SAF Reference Number (field 136) when sending a POSA SAF Activation/Reload transaction request message. POSA SAF requests also require that the POSA Stand-In Indicator (Field 135) be set to a value of “Y” in the transaction request message.
• For 'MasterCard values, please, refer o the specification of the processor for more information.

VISA Validation Code.

This four-character field must appear in the following message types:

• 0100 EFT partial reversal request
• 0110 Authorization response
• 0220 Financial request (Bit Map Type 04, 24)
• 0210 Financial response
• 0230 Financial response
• 0410 Reversal response

For VISA transactions, the code in the field is used to determine the accuracy of the authorization data. It is generated by VISA using a VISA-proprietary algorithm based on the following request and response data fields.

Primary Account Number Authorization Identification Response
Transaction Amount Response Code
Merchant Type Payment Service Indicator
POS Entry Mode Code (positions 1-2) Transaction Identifier

For MasterCard transactions, this field contains the Banknet date.

Cardholder Identification (AVS).

This 29-character field must appear in the 0100 authorization request or 0200 financial transaction request message when the Bit Map Type is 05, 06, 25, or 26. It contains the data used for address verification.

The field contains two data subfields:
The first 20 positions are the cardholder’s address data, left justified and space filled; the last nine positions contain the ZIP code. If the ZIP code is present, it must be either five or nine characters in length, left justified and padded with spaces if only five characters.

Point-of-Service Device Capability Code.

This two-character field must appear in the following messages:

• 0100 authorization request
• 0200 financial request
• 0220 financial request
• 0400 reversal request

The field contains two subfields that indicate the type of POS device used and the device’s ability to read encoded data.

P.O. Number/Customer Code.

This twenty-character field contains the purchase order number applicable to a financial transaction or the customer code associated with a purchase card. It is required in the following message types:

• 0100 credit authorization only (Bit Map Type 21 or 25)
• 0200 and 0220 credit card requests (Bit Map Types 21–26)
• 0200 VISA POS check conversion request (Bit Map Type 16)
• 0400 VISA POS check conversion request (Bit Map Type 16)
• 0100 check verification/guarantee request (Bit Map Type 32)
• 0200 check conversion request (Bit Map Type 32)

The field is optional in the 0200 financial request for a private-label (Bit Map Type 07) or fuel (Bit Map Type 09) sale.

System Trace Audit Number (STAN).

The in-store controller creates this six-digit number at transaction time to uniquely identify the transaction. This field appears in every message type supported by the Tandem Online System and the instore controller.

Tax Amount.

This nine-digit field appears in 0100 authorization requests and 0200 financial requests that apply to corporate or purchase credit cards.

It contains the dollar amount of tax included in the transaction, in the format 999999999. Sending a value of all 9’s (999999999) in the request message indicates that this is a non-taxable transaction. Sending a value of all 8’s (888888888) in the request message indicates that this is a tax-exempt transaction.

Note: For non-corporate/purchase cards, this data element can be sent as all zeroes.

Additional Data, Private EBT.

This 15-byte field is conditional in the 0200 financial message. Present only when the processing code indicates an EBT transaction, it contains the voucher number required for clearing EBT voice authorizations.

Card Sequence Number.

The three-digit card sequence number field is conditional in the 0200 financial request message when the processing code indicates an EBT transaction. The field is required only if the card has a generation number and the card was not swiped.

The card sequence number distinguishes between separate cards with the same primary account number.

Trace Data 1.

In the host capture terminal message set, this 16-character field must appear in the 0800 (Bit Map Type 02) and 0810 (Bit Map Type 94) network management request and response when processing the line management test function (echo test).

The field is included in all controller messages as an echo field for the controller’s use.
The Tandem Online System echoes the data exactly as it was received.

DUKPT Serial Number.

For PIN-based transactions using DUKPT encryption, this is the 20-character terminal serial number used in the encryption process. This field is populated by the POS system (typically from the PIN pad) for every PIN-based request.

Can be spaces in 0400 reversal requests.

Local Transaction Date.

The six-digit transaction date appears in all request messages handled by the in-store controller; it indicates the date (MMDDYY) on which the transaction occurred at the point of sale.

In 0400 reversal/void requests, this field represents the transaction being voided; see 07 Transmission Date/Time.
In a Gift Card Completion message the Local Transaction Date must be populated with the Local Transaction Date received in the Gift Card Preauth approval message.
In an Unsolicited Reversal the Local Transaction Date must be populated with the Local Transaction Date received in the original Authorization request message.

Julian Day/Batch Number.

This six-digit field appears in the 0210 and 0230 financial response and 0410 reversal response messages. It indicates under which batch the EFT transaction was captured at the host. The field contains the three-digit Julian day when the batch was opened and the three-digit batch number. (The batch number increases by one whenever a batch is released and resets to one for each Julian day). The field does not appear if Bit Map Type is 99.

Network Mnemonic/Card Type.

This field serves one of two purposes, depending on the transaction type.

The two- to four-character Card Type appears in the 0110 purchase/corporate card, check verification/guarantee authorization responses, 0210/0230 credit, check conversion responses, and 0410 reversal response messages for credit transactions and check conversion reversals.
The value is controlled by the in-store application and the Tandem Online System (BIN table).

The third character, when present, indicates the card category.

• L (Business-to-Business settlement match edits eligible card),
• B (Business),
• R (Corporate), and
• S (Purchase)

are the VISA purchase-card categories;

S is the MasterCard purchase-card category.

The fourth character, if present, is the authorization source indicator returned by Visa. The code is left justified with the remainder of the field space filled.

Example of network switch value for payment type DB is “MAES“, for payment type EB is “EWA1”.

Demo Merchant Flag.

This single-character field appears in the 0210 and 0230 financial response and 0410 reversal response messages. It indicates whether or not the terminal is being operated in demonstration or production mode. Does not appear if Bit Map Type is 99.

• ‘Y’ = Demo mode;
• ‘N’ = Production mode

Error Text.

This 20-character field must appear in all response messages when the Bit Map Type is 99 (i.e., error responses). The field indicates an error condition; the text is displayed on the POS terminal.

Response Code.

The three-digit response code must appear in all response messages when the Bit Map Type is 99 (i.e., error responses). In the case of the 0330 file update response (Bit Map Types 81 and 89), both approval and error messages include the response code. This field is used to further define the cause of a decline or error response, and is displayed in the scroll area of the terminal.

POSA Prepaid Transactions
When error response code values of “001” or “795” is received, the POS device should place the transaction on a store-and-forward (SAF) queue for retransmission. SAF request messages must have the POSA-Stand-In indicator (Field 135) to “Y” and include the POSA SAF Reference Number (Field 136) of the original transaction when available.

The POSA SAF Reference Number is provided in field 105.3 of the response message. A POS device time-out should be treated the same as receiving a “001” response code except that the POSA SAF Reference Number should be set to spaces. If SAF queuing is used, the POS should use parameters to determine number of retries and retry interval.

Working Key.

The 16-character working key appears in all response messages. It is not used when DUKPT encryption is employed.

The field will contain blanks if the host does not require a key exchange. If the field does not contain blanks, the terminal uses this working key for future debit/EBT transaction processing.

Additional Amounts.

This 20-byte field contains information — up to six amounts and related account data — for which specific data elements are not defined. It is used in 0110, for Premier Issue Mass Transaction, EBT and used in 0210 for EBT, POSA Prepaid and Gift Card responses, where it contains balance information.

Local Transaction Time.

The six-digit transaction time appears in all request messages handled by the in-store controller; it indicates the time (hhmmss) at which the transaction occurred at the point of sale.

In 0400 reversal/void requests, this field represents the transaction being voided; see 07 Transmission Date/Time.
In a Gift Card Completion message the Local Transaction Time must be populated with the Local Transaction Time received in the Gift Card Preauth approval message.
In a Unsolicited Reversal the Local Transaction Time must be populated with the Local Transaction Time received in the original Authorization request message.

POSA Network ID.

This four-byte field defines the POSA network used to authorize the POSA transaction. This field must appear in all POSA transactions. POSA networks are:

• “SWAY” Safeway
• “INCM” InComm
• “PRES” PreSolutions
• “SVSG” Stored Value Systems
• “VALU” ValueLink
• “ “ Non POSA card (spaces)

If the merchant is processing POSA cards, but the point-of-sale system is unable to determine the POSA Network, then that merchant can only successfully process for a single POSA network. In this case, the POSA Network ID field must be set up at the point of sale to always indicate the merchant’s selected network (e.g. SWAY). The value should either be hard-coded into the system or set as a parameter. If the merchant also sells their own gift cards via non-POSA networks, then the BIN range(s) for the merchant’s gift cards must be registered with Vantiv, LLC (Tandem Onlines) for processing.

Notes: Merchants that do not participate in POSA need to fill the POSA Network ID field with spaces. Contact Vantiv, LLC for current supported networks.

POSA UPC Data.

This twenty-byte field contains the POSA scanned UPC (bar code data) on the card used to authorize the POSA prepaid transaction.
This field must appear in all POSA prepaid transactions

POSA Stand-In indicator.

This one-byte field is used to indicate a POSA store and forward transaction request due to a merchant stand-in condition. Applicable to POSA activation and reload SAF transaction requests only. Use a value of “Y”, if the POS device has timed out or the host responds with response code “001” or “795” and load the POSA SAF reference number into field 136 of the request message. The POSA SAF Reference Number is returned in field 105.3 of every POSA response message, and should be retained for use in any SAF retransmission request.

When setting the POSA Stand-In indicator to “N”, the POSA SAF reference number must be initialized to spaces.
This field must appear in any POSA activation or reload SAF requests when the transaction is queued for re-transmission by the POS device.

POSA SAF Reference Number.

This twelve-byte field contains a unique number generated by the host for each POSA prepaid transaction.

The host returns this value on every POSA prepaid transaction that is approved or declined (see field 105.3 – Transaction Identifier). In a Store-and-Forward scenario, where the transaction is queued for retransmission by the POS device this field contains the POSA SAF reference number of the original Activation/Reload transaction in the POSA prepaid request message. If a POSA device time out occurs no POSA SAF Reference Number is available then set the POSA SAF Reference Number to spaces and the POSA Stand-In Indicator (field 135) to a value of “Y”.

Replacement Amount.

In a partial authorization reversal, the Replacement Amount reflects the corrected total amount of the authorization for the transaction. For a partial reversal, the Transaction Amount field must contain the original amount authorized. The host subtracts the Replacement Amount from the Transaction Amount to determine the amount being reversed. For timeout reversals, and for other cases where the original authorization is to be fully reversed, the replacement amount must be zero.

The replacement amount must not be equal to or greater than the transaction amount. Partial reversals are currently only supported for VISA and MasterCard payment types.

Point-of-Service Entry Mode.

The three-digit POS entry mode field must appear in the following messages:

• 0100 Authorization request
• 0200 Financial request
• 0220 Financial request

Contains two subfields that indicate the method used to enter the primary account number (PAN) and whether the POS terminal allows entry of personal identification numbers (PINs).

Point-of-Service Condition Code.

The ten-digit POS condition code field must appear in the following messages:

• 0100 Authorization request
• 0200 Financial request
• 0220 Financial request
• 0400 Unsolicited reversal request

Contains four subfields that, together, identify the kind of terminal and indicate whether the customer and/or the customer’s credit card were present at the time of the transaction.

Acquiring Institution Identification Code.

This four-digit field must appear in the following message types:

• 0100 Authorization request
• 0200 Financial request
• 0220 Financial request
• 0400 Reversal request
• 0500 Reconciliation request
• 0800 Network management request

The code (referred to in the Tandem Online Systems as the Bank ID) identifies the acquiring institution (i.e., merchant bank, merchant grouping, or merchants’ hierarchy) for the associated Card Acceptor ID Code (the Tandem Online Systems Merchant Number).

Retrieval Reference Number.

This eight-digit must appear in the following message types:

• 0110 Check auth response
• 0210 Financial response
• 0230 Financial response
• 0410 Reversal response

The retrieval reference number is used to identify and track the original transaction. The field is conditional; it is present in the message only when the Bit Map Type is not 99.

Card Acceptor Terminal Identification.

The three-digit card acceptor terminal ID code (referred to as the Terminal ID in the Tandem Online System) identifies the terminal at the merchant (card acceptor) location at which the transaction was entered.
This field must appear in all transaction request messages.

Card Acceptor Identification Code.

The 12-digit card acceptor ID code (referred to as the Merchant ID in the Tandem Online System) must appear in all transaction request messages. This field, in conjunction with the acquiring institution identification code (Field 32), uniquely identifies the merchant in the Tandem Online System.

Lane Number.

This three-digit field appears in the following controller message types:

• 0100 Authorization request
• 0200 Financial request
• 0220 Financial request
• 0400 Reversal (void) request

It identifies the cashier location at which the transaction occurred.

Note: Of the 3 digit lane number only the right most two bytes are used. Lane numbers must be within the range of 01 to 99.

Track Data.

Track data must appear in the following message types*:

• 0100 Authorization request
• 0200 Financial request
• 0220 Financial request

This field contains up to 76 alphanumeric, encrypted, or special characters of data read from track 1 or track 2 of the magnetic stripe on the card, excluding the beginning and end sentinels and the LRC character. Tandem Onlines recommends that the data be right justified, space filled. If the cardholder information (PAN and expiration date) is manually entered, the data must be right justified and space filled in the following format.

Refer to the specification of processor for more information.

Personal Identification Number (PIN) Data.

This 16-character (64 binary bits) field may appear in the following message types:

• 0100 Authorization request
• 0200 Financial request
• 0220 Financial request
• 0400 Reversal request

The PIN data field uniquely identifies a cardholder at the POS terminal and is associated primarily with debit transactions. Each four-bit group in the field translates to a single hexadecimal character to yield a total of 16 ASCII display characters.

Can be spaces in 0400 reversal requests.

Clerk Number.

This eight-digit field appears in all controller requests that represent in-lane transactions. It identifies the employee associated with the transaction. If not applicable, the field should be zero filled.

Cash Back Amount.

This nine-digit field appears in the 0100 authorization and 0200 financial request messages. It represents the amount of money being given back to the cardholder. The entered amount can be up to seven digits; in the message it must be right-justified and padded with zeros to the full nine positions. This amount should not be included in the transaction amount field.

For AVS verification only (Processing code 514000) request, this field must be zero filled.

Contains several fields:

Invoice/Folio Number.

This six-digit field appears in the 0200 and 0220 financial messages for those transactions (usually designated for specific card types) that use the extended prompts option. The field is required when settling American Express retail transactions. If the message also includes the P.O. Number/Customer Code field (bit 109), this field is ignored unless bit 109 is space-filled.

Item Code (from one to five)

These four-digit fields appear in the 0200 and 0220 financial messages for those transactions (usually designated for specific card types) that use the extended prompts option. These fields are used to cross reference a table in the Tandem Online Systems database that designates the type of merchandise purchased. Required when settling American Express retail transactions.

Authorization Identification Response.

This six-character field appears in the following messages:

• 0110 Authorization response (controller)
• 0200 EBT voice authorization/voucher clear request
• 0220 Financial request (prior authorized sale transactions) (controller)
• 0210 Financial response (controller)
• 0230 Financial response (controller)
• 0410 Reversal response (controller)

The auth ID response contains an authorization number assigned to the transaction by the authorizing institution. In all host capture terminal messages but the EBT voice-auth request, this data is in bit 38.

Authorization Identification Response.

This six-character field appears in the following messages:

• 0110 Authorization response (controller)
• 0200 EBT voice authorization/voucher clear request
• 0220 Financial request (prior authorized sale transactions) (controller)
• 0210 Financial response (controller)
• 0230 Financial response (controller)
• 0410 Reversal response (controller)

The auth ID response contains an authorization number assigned to the transaction by the authorizing institution. In all host capture terminal messages but the EBT voice-auth request, this data is in bit 38.

Extended Payment Code.

The two-digit extended payment code field appears in the 0200 and 0220 financial request message. It pertains specifically to JCB transactions where the consumer can specify the number of installment payments they wish to make for each purchase.

Network Management Information Code.

All request message types support the following codes:

• 000 = Default (no key change required)
• 101 = Key change requested
• 900-999 = Log transaction as given error.

The Tandem Online System will record this transaction as an error transaction with the given code and the error server name as ‘SLHBAS’.

Full reversals support the following value:

400 = Suspected Fraud

In addition, message type 0800 supports the following values:

• 360 = Terminal validation
• 380 = FleetOne Batch Close

Original Data Elements.

This eight-character field must appear in 0400 reversals and the nine-character field must appear in 0100 authorization reversal request messages. It contains the retrieval reference number from the original transaction response, and helps identify the original transaction for reversal processing.
For timeout reversals where the original transaction's retrieval reference number is not known, populate this field with zeroes.

Reference to the entity that represents real-time financial transaction.

Optional Processing Indicators.

It is a series of codes that identify terminal capability, terminal environment. Refer to the specification of the processor for more information.

Merchant Reference Data.

Used in settlement to uniquely identify a merchant’s transaction. The Merchant Reference Number can be present in any 0100, 0200, or 0220 authorization request transaction.

The Draft locator ID field is a unique value assigned by the POS device for each transaction. The Merchant reference number should be a unique value assigned by the POS device for each transaction.

eCommerce Verified by VISA.

Used for eCommerce websites that support Verified by VISA (VBV) Internet payer authentication transactions. This group field can be present in any eCommerce VISA credit 0100, 0200, or 0220 authorization request transaction when VISA VBV authentication is desired. It will be ignored for all other authorization transaction requests.

Contains several fields. Each field must be 40 bytes in length. This group (G002) is not allowed in conjunction with G003. For field 03 Electronic Commerce Indicator valid values are 5, 6, 7, or 8. For a description see Bit 25 Pos Condition Code Position 4.

When present the host includes the data in the authorization request message to VISA. The response to the POS device will include an Electronic Commerce Indicator field that indicates the result of authentication.

Refer to the specification of the processor for more information.

eCommerce MasterCard SecureCode.

Used for eCommerce websites that support MasterCard SecureCode, Internet payer authentication. This group field can be present in any eCommerce MasterCard credit 0100, 0200, or 0220 authorization request transaction when MasterCard SecureCode is desired. It will be ignored for all other authorization transaction requests.

UCAF collection indicator must be one byte. If UCAF accountholder authentication value (AVV) is provided then the UCAF collection indicator must be a value of “2”. The host will ignore the UCAF AVV data if the UCAF collection indicator is a value of “0” or “1”.

Note: This group (G003) is not allowed in conjunction with G002.

When present the host includes the data in the authorization request message to MasterCard. The response to the POS device will include an Electronic Commerce Indicator field (one byte alphanumeric character), which indicates the result of authentication.

Value that identifies terminal capability, terminal environment, and point-of-interaction security data at the time a transaction occurred. The values differ by card type.

AMEX customer related data for swiped transactions that indicates whether the terminal will provide the CVV2/CID data, and what its value is.

Original Authorization Retrieval Reference Number.

Provides a way to send an original authorization retrieval reference number.

This field should be used when sending a 0220 force post. It should also be used with all full and partial reversals. This enables the Host to retrieve the original authorization information (if still available) to supplement settlement data.

Note: Must be numeric. Any invalid data will be ignored by the host.

Additional Amounts Request.

This 20-byte field contains information — up to six amount sets.

The presence of this group is mandatory and indicates to the host this is an IIAS transaction request.
The presence of G015 is optional in an EBT WIC authorization request transaction.

IIAS transaction request:
Amount type 4S must be present. The sum of the additional amount type fields must not exceed the total healthcare amount (4S). Any amount type can only appear once.

EBT WIC transaction request:
Only a single amount type 52 can be present in an EBT WIC authorization request transaction.

Refer to the specification of the processor for more information.

Specific Card information capture conditions that were present at the time a card transaction took place at the POS.

Fee Data.

Use this group to send convenience fee data. Please refer to card association regulations for details regarding fee usage.

Convenience fees can be sent in a single transaction (Fee Type = 1) or in two transactions (Fee Types 2 and 3).

For a single convenience fee transaction (Fee Type 1):

put the fee in the Fee Amount field of this group and also include it with the Transaction Amount.

For a two-step convenience fee transaction:

1. The first transaction must have Fee Type = 2 and Fee Amount = zero.
2. The second transaction must have Fee Type = 3 and both Transaction Amount and Fee Amount containing the convenience fee.

VISA CPS/Debit tax fees must be sent in a two-step transaction (Fee Types 2 and 3).

For a two-step VISA CPS/Debit tax transaction convenience fee transaction:

1. The first transaction must have Fee Type = 2 and Fee Amount = zero.
2. The second transaction must have Fee Type = 3 and both Transaction Amount and Fee Amount containing the convenience fee.

VISA limits the convenience fee amount for CPS/Debit Tax fee payment transactions, it is recommended to verify the fee limits and other terms during the merchant registration process.

Restaurant Tip Amount.

Used in conjunction with a sale or adjustment message to log the tip amount received. The cents portion is the last two positions, and the decimal point is implied.

Must be numeric. Invalid data will result in a declined transaction. This group is ignored if the merchant is not configured on the host as Restaurant industry.

POS Identification Data.

These fields provide identification data for POS applications and associated devices. It is required for applications using EMV chip card technology, and will ultimately be required for all 610 applications in the future.

Tag data included for all chip card transactions. EMV chip card data determined by the POS application and chip card involved in the transaction.

Credit card PIN data used for standard magnetic stripe swiped transactions and EMV online PIN verification transactions.

Additional request information that can contain multiple tags in any order with different information.

Identifier of the object used for references; auto-incremented integer value.

Indicates whether the processed transaction is debit type.

Indicates whether the original transactions was already reversed.

Code of Merchant Account to which instance of this object is attributed to. Depending on the context, Merchant Account Code field may contain either Merchant Code or Merchant Account Code.
The field is primarily used for data partitioning and data management, to make it easy to determine the ownership of a record within the database.

Appears in every message type supported by the Tandem Online Systems host capture message set.

The first two digits identify the class of the message (authorization, financial, reversal, and so on); the last two digits represent the message function (request or response).

Сan be used to route the transaction through the front-end communications network (for example, CompuServe’s Routing Identifier – CRI). It appears in all messages, but is ignored by the Tandem Online System.

eCommerce VISA Authentication Result.

Used to indicate the result of an eCommerce VISA transaction that requested authentication. This response is only applicable to VISA transactions when G002 is sent in the request message.

Notes: Non-U.S. acquired transactions that occur on cards issued in the U.S. region can receive a CAVV result code values of 7,8,9, or A.
V.I.P. will reject a transaction with Reject Reason Code 0193 (invalid value) when an issuer returns the response message with the value C or D.

Card-Level Results.

The field contains a two-character code created by Visa during the authorization process. Refer to the specification of processor for more information.

Additional Amounts.

This 20-byte field contains information — up to four amount sets. This group is returned when the transaction has been partially approved and on balance inquiries. Refer to the specification of processor for more information.

Original Authorization Retrieval Reference Number.

This group is used to respond with the retrieval reference number of the authorization transaction. To request this group to be returned the sixth byte of G009 (Optional Processing Indicators) on authorization request has to be set to “Y”.

AMEX Transaction Identifier/Discover Network Reference ID.

Used to pass the AMEX Transaction Identifier/Discover Network Reference ID. This response group is returned on approvals or declines when G009 position 4 in request is set to "Y" and the American Express transaction was sent to American Express for authorization, or when G009 position 9 in request is set to "Y" and the Discover transaction was sent to Discover for authorization.

EMV Response Data.

EMV tag data format is BER-TLV as defined in ISO/IEC 8825. The tag data is Base64 encoded.

This group contains the Base64 response data returned by the issuer or networks for EMV chip card transactions. The POS device must be prepared to receive this group even on declines.

Note: Since the 600 and 610 message formats do not allow for the presence of binary data, the POS device must convert the ASCII Base64 data back to binary tag data for TLV decoding.

MasterCard Additional Processing Information for Chip Transactions.

MasterCard DE 48, subelement 74 (Additional Processing Information) provides additional information about chip transaction processing and results. Terminal applications may receive R025 if issuers performing chip cryptogram validation return their validation results.

Terminal applications request this group by setting G009 position 18 to “Y” in the transaction request.

Refer to the MasterCard Customer Interface Specification, section "DE 48 - Additional Data - Private Use, Subelement 74 - Additional Processing Information" for complete details and current list of valid values.

Visa Spend Qualified Indicator.

Indicates if the account has met its’ spend qualification threshold.

Refer to the Visa Base I Technical Specifications, Volume 1, section "Field 62.25 – Spend Qualified Indicator" for complete details and the current list of valid values.

Pinless Debit Indicator.

This response field indicates that the transaction was processed as a pinless debit transaction.

This flag will be returned only if the transaction processed as pinless debit. The terminal does not need to send any information in the request to receive this response field. The merchant record must have the MERC PINLESS Eligible flag set to Y and the IBM must have processed the transaction as pinless debit rather than credit. If this response field is returned it will always contain a Y, if the response field is not present it indicates the transaction was processed as it was originally sent and not flipped to debit.

Error Group Data Response.

This group response is applicable to any transaction that sends group data in a request message and is determined by the host that it is invalid.

Note: A value of “00” in the group field indicates group level error no specific field.

Used to indicate any errors found by the host when processing authorization requests that contain any optional group data. Refer to the specification of processor for more information.

Reference to the entity that represents a group of real-time transactions which must be settled together.

Specific identifier associated by a processor.