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 setup receives a 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), the card data is 'tokenized', removing the card details (name, numbers, address, etc) and stores that 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, nor a Guest - can view or use that token except the network setup with the EMV device and 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, 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 '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 cars are always tokenized when received by BookingCenter - this is full tokenization.  In this case, even with taking a card over the phone it becomes tokenized when saved into a booking. The other option is to onlyTokenize 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

Therefore, any card that exists within MyPMS can be masked or tokenized depending on how your 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.