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 Description
Authorization Only (Type 01) Auth Only is the beginning of an electronic payment transaction.
Prior Authorization (Type 07) Changes an existing Auth Only (Type 01) to a Prior-Auth (Type 07) for settlement. Prior authorizations can also be performed on Forced / Voice Auth Only (Type 01) transactions.
Return (Type 09) Debit transactions should follow the standard online PIN process.
Void Return (Type 17) It voids an existing Return (Type 09) transaction and changes the status of the return transaction to a voided transaction.
Transaction Inquiry (Type 22) Performs transaction status inquiry.
Full Authorization Reversal (Type 61) Can be performed on an open authorization, to reverse it and return the open-to-buy to the cardholder. 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.
Incremental Authorization (Type 75) Used to secure additional authorization for an on-going, previously authorized transaction. Type 75 is limited to certain card types.
Partial Authorization Reversal (Type 76) Can be performed by the PMS prior to submitting the final transaction as a Prior Authorized Sale (Tran Type 07) or can be performed by Fusebox at the time of settlement.

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.

error_outline
note

Not all TPPs support an Incremental Authorization transaction, and internally, Fusebox may change the transaction to an Authorization Only (often called an Additional Authorization), which is typical in regions outside of the United States.

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

error_outline
note

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

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.

error_outline
note

For the lodging industry, some card association brands may offer the same interchange rates for card present and card not present, whether the card information is manually entered or swiped, as long as the correct data elements are presented.

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.

error_outline
note

As a guideline, Elavon recommends using 14 days as the maximum time for all credit cards.

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