MyCard EMV

MyCard EMV^© is BookingCenter's credit card payment gateway for EMV terminals that is tightly integrated with MyPMS^©. It is intended to be transparent to the user and eliminates the need for separate POS, additional phone lines, monthly and transaction fees as well as the time intensive auditing of settlement reports against MyPMS audit reports.

Managing Credit Card Transactions with MyCard EMV^©

When setup with MyCard EMV^©, when you add a credit card from the New Booking window, the Booking Data tab, or the Manage Credit Cards screen, an option to 'Swipe/Dip' is presented in addition to the Manual Transaction/Swipe' method used in Traditional MyCard^©.  The 'Swipe/Dip' option awaits input from the EMV device and enters the authorization with an (E) that shows the transaction was a 'dip' or 'tap' from an EMV device. See the following functions below for specific tasks.

Tokenization in MyCard EMV^©

When an EMV property receives a credit card - when saved during manual input into the PMS; when entered by a guest into an online booking; or sent from a GDS or OTA (such as Expedia or booking.com) booking, the card data can be 'tokenized' to remove the card details (name, numbers, address, etc) and stored as a 'token' to be used for an authorization or payment (purchase or credit). The benefit of a token is that no one - not your staff, not a hacker into your network or BookingCenter's, nor a Guest - can view or use that token except the property setup with the EMV device and/or account. Thus, it provides the best level of security for storing credit card data.  

The card looks like a familiar one stored as a payment option on Folios, but there are a few differences:

• Example of a Tokenized EMV saved credit card: (this is a MasterCard ending in #1513 with expiration of 08/27 and has a .20 authorization saved on it)
• Example of a Non-Tokenized saved card, still masked, but not using EMV tokenization: (this is an American Express ending in #2000 with expiration of 09/26 and has a .0 authorization saved on it).

They both look similar to your staff, but the Tokenized card cannot be seen by anyone; the non-tokenized card is stored encrypted and 'masked' so staff won't see it. But if the User is set to 'View credit Cards', that card data can be viewed by a Manger with access to that privilege.  Thus, security is weaker for a non-tokenized card.  Both approaches can pass PCI compliance, since the card is stored securely (BookingCenter use 256-bit encryption to store and 'view' the card data) and access to the data is reserved for only Users with legitimate business purposes, which many hotels require for charging 'cancellation', 'no show' and other fees, thus allowing PCI compliance.  But clearly one approach offers an opportunity for fraud, the other doesn't.

Hybrid Tokenization Option

BookingCenter offers two settings where the card can be tokenized on the ‘save’ (or entry) meaning all cards are always tokenized when received by BookingCenter - this is full tokenization.  In this case, even when taking a card over the phone it becomes tokenized when saved into a booking. The other option is to only Tokenize the card when issuing an authorization, which happens automatically when issuing a manual authorization, payment, or credit ('refund') to any Folio.  Thus BookingCenter gives you two options to tokenize cards

1. On Entry
2. On Use

Any card within MyPMS can be masked or tokenized depending on how you wish to manage the risk of credit card data.  Contact BookingCenter if you wish to discuss the pros/cons of your operational needs as it applies to credit card fraud risk.

Use cases and associated settings

Settings that have an effect on your MyCARD EMV process.

1. Auth at check-in - This setting is redundant if the process is to swipe/dip all cards at check-in. An authorization is created during the swipe/dip process negating the need for an auth at check-in setting. Technically this should not cause an issue. The issue we see happen when using auth at check-in is that the card listed in the guarantee is the card that gets authorized. This may not be the dipped card in which case you could potentially be authorizing the card 2 times, one as card not present (the guarantee card), and the other card used in the swipe/dip (card present) process.
2. Pre-auth of a card prior to check-in - If you have a authorization on a card prior to arrival and then dip the card at arrival a new authorization is created, thus, there are 2 authorization for this booking. In this case you would need to then void the previous authorization on the manage credit cards screen. With the EMV device you want to only use the, card present (swipe/dip) authorization for all payments and not the previous, card not present (manual card entry or card imported with online booking) authorization. 
3.  Deposits - A deposit on a booking prior to check in will not effect the swipe/dip process at check-in.  The user should be aware of the deposit on the booking and the swipe/dip amount authorized should be adjusted accordingly (deducting the deposit amount from the projected total).

A typical use case for EMV is that the booking is made ahead of time and a credit card is attached to the booking.

A property that takes payment at time of check-in

1. The guests arrives, take the card and dip into the device with an authorization for full projected income of the booking.
2. On the folio post the full payment for the stay to the card listed in the dropdown with the "E" designating it at the swiped/dipped card 
3.  Guest is now checked-in and the payment in full is posted to the folio

A property that takes payment at check-out

1. The guests arrives, take the card and dip into the device with an authorization for full projected income of the booking.
2. Do not post a payment to the folio
3. Guest is now checked-in and final payment is collected at time of departure using the card in the payment dropdown with the "E" designation.