Best Practices

This section provides recommendations and examples of how transactions are handled within the lodging industry and how they impact qualifying for the most favorable merchant interchange rates and fees.

Reservations

Most hotels accept guest reservations online or by phone. To verify that the cardholder and credit card are valid, use the following transactions:

• Account Verification (Tran Type 01) - We recommend processing an Authorization Only for $0.00. An Account Verification for $1 can be processed (if a $1.00 Authorization is performed), as long as a Full Authorization Reversal (61) is submitted immediately afterwards.

• The reference number (API field 0007) must be unique.

• If a Card Verification or Authorization Only-transaction is performed during the reservation, the Program Code (API field 0305) in the input request must have a value of 1. This transaction can be used to obtain a token or unique ID, but cannot be used as the first authorization in a transaction lifecycle or settled at any point.

For example, if the card is verified using Auth Only (transaction type 01) for $0.00 (a non-financial zero-dollar authorization), the cardholder’s account information is verified, it does not negatively impact a cardholder’s open to buy, the AVS and CCV2/CVC2/CID are validated, and a token or unique ID can be requested during this transaction.

American Express and Discover may require the Billing ZIP/Postal Code and CCV2/CVC2/CID. Also, there is potential for a transaction fee assessment.

Advance Deposits or Prepayments

During the reservation process, some hotels require or allow guests to pre-pay an amount toward their final bill. Support for advance deposits or pre-payments involve using one of the following transactions:

• An Authorization Only (Tran Type 01) or a Prior-Authorized Sale (Tran Type 07)

Additional Requirements

• The amount of the Advance Deposit / Prepayment transaction should not exceed the cost of a 14-night stay.

• The Arrival Date (API field 0303) must have the reservation arrival date (future).

• The Program Code (API field 0305) must have a value of 3 (Advance Deposit).

For example, if an Advance Deposit in the amount of $100 is made using Auth Only (Trans Type 01) followed by Prior Auth (Trans Type 07), the cardholder’s account information is verified, it does not negatively impact a cardholder’s open to buy, the AVS and CCV2/CVC2/CID are validated, and a token or unique ID can be requested during this transaction. American Express and Discover may require the Billing ZIP/Postal Code and CCV2/CVC2/CID. There is also a potential for a transaction fee assessment.

Check-In

Your PMS application initiates an Authorization Only (Tran Type 01) when a guest arrives at the hotel. Even if the account number, token, or unique ID is available from a reservation, the credit card’s magnetic stripe should be read as part of the guest check in process. This transaction is acceptable for a credit card. However, a PIN Debit or EMV transaction may require a one-part Sale (02) transaction with PIN entry. For information regarding PIN Debit or EMV, refer to the EMV section.

Ensure that the Reference Number (API field 0007) is unique. Do not use the same Reference Number that was generated for the reservation transaction.

Additional Requirements

• The amount authorized should not exceed the estimated cost of a 14-night stay.

• The Program Code (API field 0305) must have a value of 1 (default).

• Some hotels routinely authorize more than the total room charges to cover any incidentals a guest may incur. This amount should not exceed 15% more than the total of the room charges

For example, if a Folio is opened in the amount of $100 is made using Auth Only (Trans Type 01), the cardholder’s account information is verified, it is the ideal interchange qualification, and a token or unique ID can be requested during this transaction. There is potential for a transaction fee assessment.

Authorization Maintenance

Fusebox supports the following transaction types when making any adjustments between the total amount authorized and the anticipated final amount:

• Full Authorization Reversal (Tran Type 61)

• Incremental Authorization (Tran Type 75)

• Partial Authorization Reversal (Tran Type 76)

• Full Authorization Reversal (Tran Type 61)

When the estimated charge increases because the guest extends their stay or adds charges to the room such as a dinner, an Incremental Authorization should be submitted to ensure that the total authorized amount is close to the final payment amount. If an Incremental Authorization is not supported due to the region or card type of the transaction, Fusebox will automatically attempt an Additional Authorization (01).

If the guest checks out earlier than expected or charges were over-estimated, a Partial Authorization Reversal should be submitted to reduce the total amount authorized and bring it within tolerance of the final amount.

Incremental and Reversal transactions are not supported on all card types in all regions. However, these transactions should always be attempted, and the results will be indicated in the Fusebox Integration Guidefinal four output response fields (two of the final four API fields contain TPP responses (1004 and 1009), the other two contain responses from FuseBox (1003 and 1010)).

For example, if an Incremental Authorization (Type 75) is performed for the $100 (for a total authorization of $200), the cardholder’s account information is verified and a token or unique ID can be requested during this transaction.

Check-Out

A guest account is closed when the guest checks out. At checkout, the final payment amount is entered into the PMS application, which generates the Prior Authorized Sale (Type 07) to end the transaction life cycle. This transaction culminates all previous authorizations performed on the guest’s credit card.

Fusebox is automatically configured for Auto-Authorize Difference for lodging merchants. Your PMS application should periodically compare the total amount authorized on the folio against the anticipated final amount and obtain any incremental authorizations. If incremental authorizations are not obtained until the guest checks out, the merchant is placed at risk because there may not be sufficient open-to-buy available for the additional charges.

If the application needs to reverse or cancel an outstanding authorization, the PMS needs to submit a Full Authorization Reversal (Type 76) for the total amount.

There are two scenarios for check out:

1. If the final amount is greater than 10% to 15% of the total authorized amount, the Folio is adjusted or corrected using a Partial Authorization Reversal (Type 76) transaction. The amount (Field 2) shows the final amount, and the approval code is the same as an Authorization Only transaction. The open-to-buy is returned to the cardholder as soon as possible, if supported.

2. If the authorization estimate exceeds the final amount, the Folio is closed using Prior Authorization (Type 07). The amount (Field 2) shows the final amount, and the approval code is the same as an Authorization Only transaction. If the Authorization Tolerance setting is enabled, a Partial Authorization Reversal (Type 76) is automatically performed to bring the final transaction within allowed authorization tolerance at the time of Settlement. This is an ideal interchange qualification, an ideal authorization-related chargeback protection, and results in economical transaction fees.

No Shows

Some hotels charge one night’s lodging for guests who fail to check in on a guaranteed reservation. The guest may successfully dispute this charge, referred to as a No Show charge.

When the reservation is made, the hotel must obtain the account number, expiration date, and name on the guest’s credit card. The hotel must inform the guest of the hotel’s exact address, the cancellation policy for guaranteed reservations, and the charge that will occur if they do not cancel or check-in. A reservation confirmation must be mailed or emailed to the guest.

If a Card Verification (Authorization Only) transaction is performed during the reservation, the Program Code (API field 0305) in the input request must have a value of 1.

If the guest fails to cancel or check-in (as a no show), a payment for one night’s lodging, plus the applicable taxes must be posted and settled within two days. When the Sale or Authorization Only followed by Prior-Authorized Sale is created for this payment, the Program Code (Field 0305) in the input request must have a value of 2 (Assured Reservation No Show). If the proper value is not entered in the Program Code field, the transaction will be charged back to the hotel if the guest disputes it.

A credit card receipt must be provided to the cardholder. The receipt must meet the requirements outlined for any credit card receipt, and the words “No Show” should be printed on the signature line.

For example, if a Folio is opened and then closed using Authorization Only (Type 01), the cardholder account information is verified, and it is an ideal interchange qualification. However, there is the potential for a transaction fee to be assessed.

If the Folio is closed using Prior Authorization Sale (Type 07), the cardholder account information is verified, and it is an ideal interchange qualification. There is no potential for a transaction fee being assessed.

Delayed Charges

Delayed charges include any charges added to a guest’s account after checkout and after the receipt has been signed. Delayed charges can be assessed for items charged to the room (or for which the guest was responsible) that were not included in the Folio at the time the guest checked out.

This transaction should be submitted as an Authorization Only (Type 01) followed by Prior Authorized Sale (Type 07). In the input request, the Program Code (Field 0305) should have a value of 4 (delayed charge). The Extra Charges Amount (Field 0311) and Extra Charges Reason Code (Field 0312) must also be supplied to describe the charge.

For example, if a Folio is opened and then closed using Authorization Only (Type 01), the cardholder account information is verified. However, there is the potential for a transaction fee to be assessed.

If the Folio is closed using Prior Authorization Sale (Type 07), the cardholder account information is verified, and there is no potential for a transaction fee being assessed.

Express Services

Some hotels offer their guests express services, such as express check-in and express checkout. To handle these services, you may need to incorporate additional functionality into the PMS application and the hotel’s procedures.

Express check-in services usually involve a speedy method for getting guests into their rooms. Even if the guest’s credit card account number was obtained during reservations, the hotel should obtain the magnetic stripe information from the guest’s credit card prior to issuing the room key.

Express or priority checkout services usually involve allowing a guest to check out without stopping at the front desk. When a hotel supports this service, at some point during the guest’s stay the guest’s signature and mailing address must be obtained from a registration card or an Express Checkout agreement that is kept on file at the hotel.

When the payment is posted and settled, a Prior-Authorized Sale is created. The Program Code (Field 0305) in the input request should have a value of one 1 (default).

Extended Stay

Your integration must consider extended hotel stays. This is particularly important if the stay extends beyond 14 days (extended stay).

Most hotels have a policy for how frequently a guest must make a payment on their account. Some hotels request a payment every seven days. An Authorization Only (Type 01) and a Prior-Authorized Sale (Type 07) must be processed for the number of days according to the hotel’s policy on extended stay.

According to payment service industry guidelines, the recommended maximum number of days that an account can be authorized is 14 days. Elavon recommends that the PMS application be designed with 14 days as the maximum.