Lodging

A lodging integration uses only a few of the many transaction types available. Below is a list of the transaction types used in our integrations.

Transaction Type

• Authorization Only (Type 01)
• Prior-Authorized Sale (Type 07)
• Return (Type 09)
• Void Return (Type 17)
• Transaction Inquiry (Type 22)
• Full Authorization Reversal (Type 61)
• Incremental Authorization (Type 75)
• Partial Authorization Reversal (76)

Industry Requirements

The following regulations apply to the lodging industry.

Amount Tolerance

The acceptable tolerance (difference) between the total amount authorized and the final amount is between 10 and 15 percent depending on the card product and region.

If the total amount authorized and the final amount is different (out of tolerance), the transaction is not in compliance with industry requirements. Elavon offers options to lodging customers to ensure that transactions are submitted for settlement within acceptable tolerance parameters.

Authorization Practices

The Card Associations require that the total amount authorized not be less than or exceed 10 to 15 percent of the estimated final transaction amount. This requirement is intended to aid in the management of a cardholder’s open to buy.

When a guest checks in, the authorization amount is normally based on the anticipated length of stay, room rate, applicable taxes, service charge rates, and an estimate of any ancillary charges.

As part of the End of Day (EOD) or night audit process, when a guest extends the length of stay, or has spent more during the stay than was anticipated, the PMS application is used to obtain any additional authorization required to cover the difference between the total amount previously authorized and the anticipated final amount on the folio. The difference in authorization amount must be reasonable while the guest is in resident. Hotels that over-authorize a guest’s card may limit the cardholder’s ability to use the card for other purchases.

Incremental Authorization

In the event that the amount authorized is not enough to be within tolerance during the guest stay or at checkout, the PMS can initiate an Incremental Authorization (Tran Type 75) to increase the authorized amount from the original authorization.

Partial Authorization Reversal

In the event that the total amount authorized exceeds the final transaction amount (plus 10 to 15 percent), a Partial Authorization Reversal (Tran Type 76) is required to comply with the proper qualification requirements. This transaction can be performed by the PMS prior to submitting the final transaction as a Prior Authorized Sale (Tran Type 07) or it can be performed by Fusebox at the time of settlement.

The timing of a Partial Authorization Reversal is important to restore the open-to-buy to the cardholders account. In most cases, a Partial Authorization Reversal is processed in real-time to the TPP when presented by the PMS prior to the Prior Authorized Sale. If the Prior Authorized Sale is presented by the PMS with an amount outside of the tolerance, the Partial Authorization Reversal will not be performed by Fusebox until the settlement is processed to the TPP.

Not all card products, regions and issuers support a Partial Authorization Reversal at this time, but all should be attempted. The result of the Partial Authorization Reversal will be communicated to the POS.

Before a Full Authorization Reversal (Tran Type 61) became available, it was common practice to use the Partial Authorization Reversal (76) to remove all but $1.00 of the open-to-buy. You must migrate this functionality to the Full Authorization Reversal (61). When you do this, you avoid a Misuse of Authorization fee.

Full Authorization Reversal

In the event that a cardholder no longer wants to pay with a card the PMS has already authorized, the entire open-to-buy must be restored. A Full Authorization Reversal (61) can be performed on an open authorization to reverse it and return the open-to-buy to the cardholder. This transaction should be performed on all card types at the point where the authorization is not going to be settled. Common reasons to do this are:

• Wrong card was presented for authorization

• Customer wants to pay with another card at checkout

• Customer put a card on file for incidentals and there are no charges

Full, Unaltered Magnetic Stripe Data

The full, unaltered magnetic stripe data (Track I or II) is strongly suggested and should be used when available for the authorization request. Card presence is a major factor in chargeback rights of the merchant. Transactions that are not card present are most commonly Advance Reservations / Deposits, Reservation No Shows, and late charges.

If the magnetic stripe data is not presented in the authorization request, an increase in chargebacks and disputes can occur. Therefore, it is important to ensure that all of the correct transaction data is presented with the transaction to defend against chargebacks.

Timeliness Presentation

The number of days between the final transaction date and the settlement date cannot be more than two processing days.

In the event that a transaction cannot be settled within this timeframe, the transaction is not in compliance with industry requirements.

Authorizations for Extended Stays

Each card issuer has a maximum number of days the amount authorized can be held.

Transaction Date

The final transaction date must be the same as the Checkout Date (API field 0304) except for the following transactions:

• No Show

• Advance Deposit

• Delayed Charge