|
|
|
Credit Card Vault
The CC Vault Function is within the property interface configuration and can be set at the property level.
To eliminate the storage of credit card numbers in OPERA, Unique IDs (encrypted credit card keys) will be used to replace any credit card numbers; thereafter, these unique IDs will be used for any of the guest's transactions at the property.
Note: Credit Card Vault can be used simultaneously with OPERA's Chip and PIN functionality.
Note: The last four digits of the credit card number and the expiration date are used in OPERA for identification purposes only. That is why the last four digits of the credit card will be displayed on screens throughout the OPERA application.
Notes: The CC Vault Function is within the property interface configuration and can be set at the property level. To create and configure this type of interface, the menu item Configuration > Setup > Property Interfaces is available to users with the correct permissions assigned.
Also, when the RESERVATIONS > PAYMENT TYPES PER WINDOW application function and IFC > CC NUMBER NOT MANDATORY FOR RESERVATIONS application parameter is set to N, the Group Rooming List will only display non-credit card payment methods in the Payment list of values.
The export files that contain clear text cc information, will now contain credit card numbers masked with 'X' and only last 4 digits will be displayed.
When searching in OPERA using a credit card number, the expiry date will have to be entered in the widget.
The Vendor certificate can be imported at the Computer Level, and with permission, all users will have access.
Working with an EFT vendor that supports OPERA tokenization, all credit card entries will be completed through the external Payment Application. This application is accessed by selecting the credit card icon that is displayed next to any credit card entry field. The MICROS Payment Application is an external software application that is not part of the OPERA application.
Based on where the MICROS Payment Application is accessed from, two different entry forms could be displayed. But the user will know that they have accessed the MICROS Payment Application because the following image will be displayed once the application is activated:
When accessing the MICROS Payment Application from the Reservation, Check In, or Multi-Payment screens and the RESERVATIONS > PAYMENT TYPES PER WINDOW application functions is set to Y, then the following credit card entry form will be displayed:
Notes: Manual entry of a credit card number cannot be completed in the above form when the GENERAL > RESTRICT CREDIT CARD MANUAL ENTRY application parameter is set to Y and an encrypted credit card reader device is attached to the workstation. When attempting to complete this action, a message is displayed stating Manual entry is not allowed. The RESTRICT CREDIT CARD MANUAL ENTRY application parameter is available only when the CC Vault Function is active and an encrypted card reader is set up, or when the CC Vault Function is active and the IFC > CHIP AND PIN application parameter are active.
From here, you would simply swipe the credit card or manually enter the credit card information. If swiping the credit card, the Credit Card, Expiry, and Name fields will be populated automatically. But the Pay Type field will not be populated until the OK button has been selected and the credit card has had its Unique ID converted. Once the ID is converted, then the credit card type will be returned and populated into the Pay Type field.
Now if the MICROS Payment Application is accessed from, for example, the Payment screen, then the following screen appears:
Notes: Manual entry of a credit card number cannot be completed in the above form when the GENERAL > RESTRICT CREDIT CARD MANUAL ENTRY application parameter is set to Y and an encrypted credit card reader device is attached to the workstation. When attempting to complete this action, a message is displayed stating, "Manual entry is not allowed". The RESTRICT CREDIT CARD MANUAL ENTRY application parameter is available only when the CC Vault Function is active and an encrypted card reader is set up, or when the CC Vault Function and the IFC > CHIP AND PIN application parameter are active.
Once the credit card has been swiped or its information manually entered, select the OK button to convert the credit card number to a Unique ID from the external application. When this action is initiated, the credit card information remains encrypted, except for the Unique ID and any additional fields, such as MPAN, ET1, ET2, KSN.
From the Configuration > Setup > Property Interfaces > Credit Card Interface > Functionality Setup menu option, if the Deposit CVV2 Check or Deposit Address Verification check box is selected, then the following MICROS Payment Application screen appears when clicking the credit card icon from the Reservation Deposit Payments screen.
Note: For any of the MICROS Payment Application methods above, if no activity is completed, application running idle, for 90 seconds after the application is accessed, then the MICROS Payment Application is automatically closed and the OPERA screen that the application was accessed from is displayed. The application will have to be accessed again by clicking the credit card button.
Where appropriate, credit card information can still be searched upon by swiping a credit card, but the credit card button will have to be selected before the search can be completed. But if the Unique ID is not stored in the database, then no information will be returned for the search. For example, say that a guest made a reservation and booked the reservation with one credit card. But when the guest arrives to check in, they give you a different credit card to swipe. The reservation will not be found because the Unique ID for the credit card swiped is not assigned to the reservation.
Note: When swiping a credit card and the cursor is in the Name field, a series of ***** are displayed and a message is displayed to notify the user that they must use the MICROS Payment Application for the credit card swipe. Once the OK button is selected on the message, then the Name field is cleared out and the user must then select the credit card icon to open the MICROS Payment Application from the Reservation Advanced search. The Search will be by credit card number/token, not by Name.
Screens where the credit card icon will be displayed when the CC Vault Function is active.
When the CC Vault Function is active and a credit card is used as the payment method for Window 1 using the MICROS Payment Application, the Swiped column will have an X when the credit card is swiped or the chip read. Now if the same credit card is copied from Window 1 to Window 2, the swiped column will be blank for Window 2. The reason is that the MICROS Payment Application removes the Track2 data from its memory as soon as the data is used in the credit card authorization message for Window 1 for security reasons. With the removal of the Track2 data, the same credit card that was copied to Window 2 displays as not swiped because it has not been verified/authorized through the MICROS Payment Application and credit card vendor for Window 2.
With the Credit Card Vault functionality active, credit card numbers will always display as masked and the user will not be able to unmask them as the Unmask Credit Cards option for specific reports will be removed.
When swiping a credit card on an encrypted credit card reader from within the MICROS Payment Application (widget), OPERA will read the configuration of the credit card reader and pass this configuration information on to the MICROS Payment Application. The widget then parses the credit card information. The Expiration Date, Name of the Credit Card holder, the last 4 digits of the credit card number, and encrypted track data are extracted and sent to the Credit Card Vendor, based on the credit card reader device configuration. The Credit Card Vendor then decrypts the data and returns a token to OPERA to be used with any following credit card transactions. These keyboard emulated encrypted card reader devices are supported: Magtek Encrypted Magnesafe, Magtek Encrypted IPAD, and IDTech Encrypted M130. Check with your Credit Card Provider to determine which one they can work with. The HID encrypted card reader Magtek DynaPro is supported with specific Credit Card Provider software that initiates the device and provides the data to OPERA similar to keyboard emulated devices. See Credit Card Reader Device for details.
When swiping a Stored Value card on an encrypted card reader, if the same credit card vendor that is used for the credit card transactions has Stored Value functionality active and is receiving the transaction, then the Stored Value transaction will send the data as encrypted. When the Stored Value transaction is not the same as the credit card vendor, then a decrypt message is sent to the credit card vendor to provide the Stored Value number to be sent out to the Stored Value vendor.
When the IFC > CHIP AND PIN application parameter is set to Y, the Credit Card Number and Expiration Date values do not need to be entered into the MICROS Payment application for a single payment method or multiple payment methods. Selecting the OK button will initiate the GetID transaction to the Chip and PIN card vendor. The Chip and PIN card vendor then initiates the CP Reader Device to read the card and provide a successful response that includes:
For properties whose EFT vendors utilize IFC8 with Vault, the CHIP AND PIN (EMV) parameter should also be active. All PMS credit card transactions go through IFC8 and do not require credit card data. The vendor must activate a device where the card data can be captured and processed. A token is returned with the vendor response and inserted in OPERA to be used with subsequent transactions.
Note: The MICROS Payment application processes one GetID request at a time when the RESERVATIONS > PAYMENT TYPES PER WINDOW application parameter is set to Y and multiple credit card payments exist per window.
The vendor response also includes, along with the token, the last 4 digits of the credit card number, the card type, and the expiration date. This allows OPERA to display the last 4 digits of the credit card number so that you can inform the guest that this specific credit card type was used for the transaction.
All bulk Vault Conversion and OEDS/OXI messages for retrieving the token and credit card number (GetID/GetCC) are sent to the token provider through the URL set in the IFC configuration.
When a profile comes into ORS/OCIS from OXI-Hub, the following will occur in the match and merge process:
Notes:
Any conversion from a credit card number to a Unique ID from the Credit Card Vault will be done on the OXI-Hub side before the value is inserted into the profile stage tables.
If the EFT system is down, a credit card number will not be stored and/or used for matching purposes.
When a new or updated reservation comes into ORS/OCIS from OXI-Hub, the following will occur:
The following will occur when a reservation is updated in OPERA and an update needs to be sent to an external third-party CRS system:
Note: If the EFT system is down, you will need to queue the outgoing message until the EFT system is back up.
When credit cards are sent through OWS/GDS/ADS channels, OEDS OAP will call the Credit Card Vault web service for credit card validation and obtain a Unique ID for the credit card number. OAP will no longer use the credit card number but will instead use the Unique ID while calling the OPERA database API. The Unique ID will be stored in the OPERA database along with the last-four credit card digits. When a response is sent back from OAP, OAP will again call the Credit Card Vault to get the credit card number based on the Unique ID. OAP will then return a credit card number in the response to the OWS/GDS/ADS channel.
When the Credit Card Vault is active, OEDS will no longer do credit card validation as this will be handled by the Credit Card Vault.
See Also
