Mercury Pay Auth Retail Transaction UML

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

This is a transaction routing and market data (allow up to 200 Alpha-numeric characters in length) and is required to be submitted with all PreAuthCapture request, with ReverseFSASale and used in conjunction with a VoidSale for Reversals.
When submitted it is always included in the <TranInfo> data node.

Sum of authorization.

Amount available on the card balance.

Amount of change after the purchase, issued in cash.

Amount of tips.

Amount of purchased goods

Authorization Code returned by the processor.

This is referred to as Address Verification Service (AVS).

Though not impacting the actual authorization approval, a better processing rate is achieved for some (retail, QSR,) merchants if address information is supplied when the card is not swiped.

The Response Code to the Address Verification Service.

Will inform the POS if the transaction was "Captured" or "NotCaptured."

Reflect the card type entered submitted ("VISA" "M/C" "AMEX" "DCLB" "DCVR" "JCB" "DEBIT" "FSA" "FSADebit" "OTHER")

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

Status, received if there are transactions with the same amount and on the same card.

Indicates the outcome of the command:
“Approved” = transaction approved by payment processor;
“Declined” = transaction declined by payment processor;
“Success” =command completed successfully;
“Error” =error processing command.

The actual PO number, the merchant’s zip code, or the transaction invoice number, will sufficient to meet the Level II reporting requirements.

A code that reflects the outcome of the CVV2/CVC2 check.

Server specific or DSIClientX specific TCP/IP six digit codes corresponding to a single or dynamic or variable message text.

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

The locally generated always incrementing individual transaction number.

Required field in all ActiveX and WebServices integrations

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.

Merchant identifier, assigned by processor.

The typical format for a Mercury Merchant ID combines an 11 digit numeric value, separated with an ‘=’ and a 6 digit alpha value as in: 884300XXXXX=ABCDEF.. Is returned without the "Nick Name" in the response.

Name of the provider account.

Generated automatically by default. Comprised of a merchant account code followed by the type of provider profile for which it is defined.

Identifier of the operator carrying the transaction.

Use of the data element will “allow” a partial approval if the balance on the card is less than the purchase amount requested.
The transaction will approve for the authorized balance amount available on the card and will not decline the transaction.

Transaction routing and market data (allow up to 200 Alpha-numeric characters in length) and is required to be submitted with all PreAuthCapture request, with ReverseFSASale and used in conjunction with a VoidSale for Reversals. When submitted it is always included in the <TranInfo> data node.

Mercury's proprietary tokenization method. This is the returned token reference.

A RecordNo will be requested with two tags:
1. the Frequency of the token requested ("OneTime" or "Recurring")
2. either a request for token ("RecordNumberRequested") or the actual token returned in the original response.

A transaction reference value returned in the transaction response and indicates that an approved transaction has been “referenced” and is added to the current batch file.

This field is used as a “filler value” on the initial request until an actual host value is returned indicating the transaction is now in the batch file; a true RefNo is returned on the response and logged at the host for all completed transactions.

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

Identifies the any error type.
Value will be zero if transaction processed normally.

See Return Codes for possible values.

Indicates the outcome of the command:
"Success" = Command completed successfully
"Error" = Error processing command by processor

Commission fee for card payment

The purchase amount tag will be the total charge, including tax.
The tax field breaks out the tax amount for Level II reporting purposes only.

TerminalID is never used on MercuryPay; always use TerminalName if requiring a terminal identifier

Optional response message from the processor about the transaction status.

The actual transactions run (as in Sale, Return, Balance, etc.) under these specific tenders.

Transaction Types include Credit, Debit, EBT, FSA, Gift/Prepaid, Loyalty, Admin, Canadian Debit /EMV and CheckAuth.

Сertain information associated with the authorization.

ZIP Code.