First Data Compass Capture Retail Transaction UML

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

Contains the credit card account number which identifies the customer. The account number is left justified with trailing spaces.

This action tells First Data what service to perform on the transaction.
We use:
RF - Refund
DP – Deposit (ValueLink)

Accountholder’s address information

Amount of transaction (echoed back from On-Line Processing Detail Record). 2 decimal implied

Authorization code of the approved, original, authorized transaction. This field cannot be blank or the transaction will reject with Response Reason Code

Response to address verification request.

Result of action requested

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

Accountholder’s city.

Accountholder’s country code.

Purchase order or other number used by merchant’s customer to track the order.

Defines whether or not the transaction has been deposited.
Valid values:
Y – Deposited
N – Not deposited

Item Description (optional). Left justified/space filled.

Notes: First Data will not pass the full 38 bytes of this field.

First Data assigns a unique Division Number to process each international currency. A single Division Number can support different transaction types and methods of payment in the same currency.

MMYY format. Send blanks if the card has expired since the order was placed or if the true expiration date is not known.
First Data assigns the appropriate default value (dependent on the card type) that indicates to the Issuer that the true expiration date of the card is unknown to the merchant.

http://unidoc.unitedthinkers.com/help/field/f2e9dfc75e0ff74891d2f716bbea113ec72b0788e2809a1314b5b9118d4b62387a9b74faae2545510ef6b9070a286f20c7be14f0258745adb103845ae2321630

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

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.

City of the merchant's postal address.

Any contact information (phone, email, street, region etc.) of the merchant.

Method of Payment (MOP) defines the MOP associated with this order.

Accountholder’s name (asterisk should precede last name).

A value composed of any alpha, blank, digit, or punctuation combination that will be returned in the transaction response. This field will tie the merchant’s request to the First Data response.
The merchant’s order number should be used to match responses with requests.

Accountholder’s postal code.

Date of approved, original, authorized transaction. YYMMDD format Response date must be current or prior date or the transaction will reject with Response Reason Code

Description of the response code

Amount of sales tax assessed to the transaction

Accountholder’s state.

Trace number returned from debit vendor

Describes the circumstances under which the transaction takes place. Default space filled.

We use:
1 – MOTO Indicator – Single Transaction Mail/telephone order: designates a transaction where the cardholder is not present at a merchant location and consummates the sale via the phone or through the mail. The transaction is not for recurring services or product and does not include sales that are processed via an installment plan.
7 – ECI Indicator – Channel Encrypted Transaction: Designates a transaction between a cardholder and a merchant consummated via the Internet where the transaction includes the use of transaction encryption such as SSL, but authentication was not performed. The cardholder payment data was protected with a form of Internet security, such as SSL, but authentication was not performed.