PaySafe Auth Retail Transaction UML

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

Account number in the system.

Acquirer authorization code.

The raw AVS code returned by the acquirer.

The balance remaining on a gift card, if a gift card was used for the original transaction.

The batch number of the transaction.

Identification code of an acquirer, such as DJN, CRX, etc.

Acquirer CVV2 verification response result.

Description of the response.

The date of the bank deposit associated with the transaction.

The type of financing offered.

The grace period, in months, associated with deferred payment transactions.

The acquirer MID that was sent to the clearing house.

The plan number for the financing transaction.

Bank Net transaction ID/Merch Tran Ref.

Request ID assigned by NETBANX.

The raw response returned by the acquirer.

The response ID assigned by Credorax.

The raw response reason code returned by Credorax.

The merchant's sequence number.

The number of payments, in months, for equal payment transactions.

The merchant's terminal ID.

The actual transaction date and time.

The amount of the request, in minor units.

For example, to process US $10.99, this value should be 1099. To process 1000 Japanese yen, this value should be 1000. To process 10.139 Tunisian dinar, this value should be 10139.

Note: If the merchant account is set up for a currency that has 3 decimal units, our system will half round up the least significant digit. Therefore, a transaction of 10.139 Tunisian dinar would be processed as 10.14.

API key of the merchant.

Authorization code assigned by the issuing bank and returned in the response.

Authorization ID.

The amount of this settlement that is available to refund, in minor units.

The amount of of the Authorization remaining to settle, in minor units.

This is the AVS response from the card issuer.

• MATCH
• MATCH_ADDRESS_ONLY
• MATCH_ZIP_ONLY
• NO_MATCH
• NOT_PROCESSED
• UNKNOWN

Month part from the expiry date, specified on the credit card.

Year part of expiration date, specified on the credit card.

Credit card number used for the request.

Type of credit card used for the request.

CAVV code of the card.

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

The child merchant account number. It is returned only if the transaction was processed via a master account.

City in the billing address.

Country code in the billing address.

Currency of the merchant account (e.g., USD or CAD) returned in the request response.

The 3- or 4-digit security code specified on the credit card following the card number.

This is the response to the CVV submitted with the transaction request.

• MATCH
• NO_MATCH
• NOT_PROCESSED
• UNKNOWN

Description of the transaction, provided by the merchant.

Dynamic description of a transaction. Appears on a statement and can be customized to simplify understanding of charge for a cardholder.

Electronic Commerce Indicator code, which gets returned by the card issuer indicating whether the cardholder was successfully authenticated.

Customer’s email address.

Code of the occured error.

Detailed description of the occured error.

The list of fields that have problems.

Short description of an occured error.

Customer’s first name.

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

The last four digits of the credit card used for the request.

Customer’s last name.

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.

The merchant reference number created by the merchant and submitted as part of the request. It must be unique for each request.

Customer's telephone number.

Indicates whether this is an initial or repeat transaction for a customer for whom you will be processing recurring transactions.

The Recurring Indicator is used to identify transactions that are eligible for repeat processing. The merchant should identity the initial transaction processed with full billing information including the card security code (CVV) by setting the recurring indicator to “INITIAL”. Subsequent charges to the same card can be identified with the recurring indicator set to “RECURRING”. For these transactions the card security code is not required and could not be passed in because card regulations do not allow merchants to store it.

Type of initiated request.

Amount specified in the response.

Code of the response.

Human readable response message explaining the response code.

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

An array of integers is returned, displaying the detailed Risk reason codes if transaction was declined.

Note: It is returned only if the account is configured accordingly.

This indicates whether the request is an Authorization only (no Settlement), or a Purchase (Authorization and Settlement).

• false – the request is not settled
• true – the request is settled

Note: This value defaults to false. If the merchant wants to find out whether an authorization has been settled, they should check the availableToSettle element. If the amount is 0, the authorization has been fully settled.

Recipient's city address used for the shipment.

Recipient's country code used for the shipment.

Name of the recipient.

Recipient's state address used for the shipment.

Recipient's street address used for the shipping.

Recipient's ZIP (or postal) code used for the shipment.

This is the 3D Secure signature verification result value.

• Y – All transaction and signature checks satisfied.
• N – At least one transaction or signature check failed.

State in the billing address.

Note: 2-character state or province codes for Canada or the United States.

The status of the authentications request.

First line of the street address in the billing address.

Indicates whether or not the cardholder is enrolled in 3D Secure.

Indicates the outcome of the authentication.

Track 1 information read from the card's magnetic stripe.

Track 2 information read from the card's magnetic stripe.

The date and time the transaction was processed.

ZIP (or postal) code in the billing address.