Credit Card Vault

The Credit Card Vault functionality can only be activated by the IFC > CREDIT CARD VAULT application function, and this is a GLOBAL function. If activated in a multi-property environment for one property, then it will be active for all the properties in the environment. Please contact your regional office to get this application function activated and to find out more details.

Note: When the IFC > CREDIT CARD VAULT application function is active, in an ASP environment, all resorts within one chain code will be vaulted but not all chain codes within a schema need be vaulted.

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. This Unique ID is then attached to the guest's profile, just as the credit card would have been, and will be used for any future stays or transactions that they have.

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 IFC > CREDIT CARD VAULT application function can be set to Y in PMS, ORS, and S&C when there is an active Credit Card Interface configured for Vault functionality. To create and configure this type of interface, the menu item Configuration > Setup > Property Interfaces is available to users with the correct permissions assigned. When the Credit Card Vault application function is set to Y, the Dynamic Currency Conversion functionality is not supported.

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 Change Credit Card Encryption Key utility will not be available when vault functionality is active.

Working with an EFT vendor that supports OPERA tokenization, all credit card entries will be completed through the external MICROS Payment Application. This application is accessed by selecting the 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:

credit_card_vault_Opera_Gateway_message_prompt

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:

credit_card_vault_multiple_payment_form

Note: 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".

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 form will be displayed:

credit_card_vault_payment_application_form

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 form will be displayed when clicking the from the Reservation Deposit Payments screen.

credit_card_vault_address_verification_form

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 button.

Searching by Credit Card

Where appropriate, credit card information can still be searched upon by swiping a credit card, but the 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 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 will be displayed when the IFC > CREDIT CARD VAULT hidden application function is set to Y for a property.

Multiple Payment Methods per Reservation Note

When the IFC > CREDIT CARD VAULT application function is set to Y and a credit card is used as the payment method for Window 1 using the MICROS Payment Application, the Swiped column will be populated with an X after the data is returned from the credit card vendor. 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.

Credit Cards on Reports

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.

Credit Card Vault and Encrypted Card Reader Devices

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.

Credit Card Vault and Chip and PIN

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:

Token
Last 4 Digits of the Card Number
Card Expiration Date
Type of Card

Credit Card Vault and IFC8

For properties whose EFT vendors utilize IFC8, credit cards can be swiped or manually entered into the MICROS Payment application (widget). These transactions (GetID Commands) are then sent to the Credit Card Vault vendor through the URL set in the IFC > CREDIT CARD VAULT WEB SERVICE URL application setting. When this GetID Request is processed by the vendor, a token will be returned to the widget and inserted in to OPERA to be used for any following transactions. The token will populate the CardID attribute in place of the credit card number for credit card transactions to and from IFC8.

For Advanced Deposit transactions that require AVS or CVV verification, no credit card information needs to be entered into the advanced deposit form. When the form is processed, the request is sent to IFC8 as a Chip & PIN transaction and the reader device will then request a credit card be swiped or have the information manually entered. Once the credit card is processed, the Chip & PIN authorization response will be returned to OPERA.

Note: The MICROS Payment Application will process one GetID request per credit card that is swiped at a time when the RESERVATIONS > PAYMENT TYPES PER WINDOW application parameter is set to Y and multiple credit card payments exists per window.

The last 4 digits of the credit card number from the IFC8 response for a Chip and Pin Authorization in a vaulted environment is retrieved. This allows for OPERA to display the last 4 digits of the credit card number so the user can inform the guest that this specific credit card was used.

Example

Set up to use IFC8 EFT for vault functionality. Chip and Pin is active. Set a VISA and DS payment type as CP types and the DS is also set for the Auth/Settlement at Checkout (CpPayOnly).

Created a reservation with a CP payment type and checked it in. The CpAuthor record is sent to IFC8 with no credit card data. But the response from IFC8 is returned and is looks like the following:

CpAuthor xmlns="x-schema:CpAuthorSchema_I" CreditcardNum="XXXXXXXXXXXX1234" ExpyDate="1611" AnswerStat="OK" AuthNum="12345678" ClearText="Approved" GuestNum="1486889" IssueNumber="12345678" Track2="" CardType="VA" SequenceNum="2" StartDate="061113" PathId="1" WSNum="1" KeyCoder="1" Cryptogram="" CardId="1E315B36F189C202"

This will allow the PMS forms to display XXXXXXXXXXXX1234 when the token is provided in the IFC8 response, along with just the last 4 digits of the credit card number.

Credit Card Vault Functionality in ORS/OCIS

Profile Matching and Merging in ORS/OCIS when Credit Card Vault is Enabled

When a profile comes into ORS/OCIS from OXI-Hub, the following will occur in the match and merge process:

A new or updated profile comes into ORS/OCIS from OXI.
The profile is downloaded from OXI with a Unique ID already attached.
Credit card matching will still occur, but the Unique ID will be used in place of the credit card number.
The Unique ID is compared to existing IDs in the system.
The rest of the profile match and merge continues as normal.
Note: 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.

Note: If the EFT system is down, a credit card number will not be stored and/or used for matching purposes.

Incoming Reservations from OXI to ORS/OCIS when Credit Card Vault is Enabled

When a new or updated reservation comes into ORS/OCIS from OXI-Hub, the following will occur:

A new or updated reservation comes into ORS/OCIS from OXI.
The external CRS receives a Unique ID at the time of creation.
The reservation is downloaded from OXI with a Unique ID already attached.
The Unique ID is compared to existing IDs in the system.
The reservation is updated or created as normal.

Outgoing Reservation Updates to Third-Party CRS Systems when Credit Card Vault is Enabled

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:

A reservation is updated in OPERA and an update is sent to the external third-party CRS system.
The EFT system is called to retrieve the credit card number based on the Unique ID.
A credit card number is returned to the EFT system, inserted into the outgoing message, and sent to the CRS system via an https connection.
The credit card number is removed from memory and never stored in the OPERA or third-party CRS database.
Note: If the EFT system is down, you will need to queue the outgoing message until the EFT system is back up.

Credit Card Vault Functionality in OEDS

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.