Opera – Technical & Functional Manual

opera

Index

Introduction 

Pelecard has integrated its’ interfaces with Oracle’s Opera. In this document, we will see visually how the interface works, with a brief explanation on each step.

Given that Opera interface has different configurations (on-premise / on-cloud), the flow of Tokenization and Payments is different with each config.

There are 3 different ways that Opera is configured:

  1. Full on-premise configuration, meaning that both tokenization and payments are done locally, with a middleman (=Belclient [Pelecard’s interface]).

  2. Tokenization on-cloud & payments on-premise, meaning that tokens will be created with requests being sent directly to Pelecard’s servers with no middleman in between. And payments will still require the middleman to handle the transaction.

  3. Full on-cloud configuration, meaning that tokenization & payments will be done directly through Pelecard’s servers with no middleman.

An explanation for different configs will be provided on the following pages.


Full on-premise configuration

When this is configured, all requests are processed through a service installed on OPI server.

Tokenization

Opera sends a Tokenization request (TransType=23) & Pelecard’s interface pops up:

After inputting the Credit Card details and pressing the blue button to proceed, if all details were inputted correctly – Opera will receive a response with a Token.

Payments – Authorizations + Completion

Most businesses deploy an Authorization (TransType=05 or 06) & Completion (TransType=07) method, meaning making Authorizations while the customer is staying in the hotel. Afterwards, on Check-Out (or any later stage of the stay), a Completion request will be sent to complete the debit on all the authorizations taken.

Flow:

  1. A TransType=05 or 06 is sent (with Token included):

  2. Belclient will open with encrypted card and expiry.

     3. Representative will continue by pressing the blue button.

     4. A response will be received by Opera with a 6-digit auth number.

After Step 4 is completed, Step 5+ may not occur right after Step 4. Depending on business logic, Step 5 can be triggered on Customer’s departure (Check-Out) when his stay is over. That is the most common method to be used, ensuring full debit completion of all the products the customer purchased.

     

  • A Debit Completion (TransType=07) will be sent, to complete all authorizations taken from previous steps.
  •  Pelecard’s client will open a different window that will show all    Auths.      

Amount in middle – Total Sum to be completed.

  • After clicking the ‘בצע עסקה’ button, all auths will be completed in the order they were taken (ascending way [Oldest to Newest]).

  • Opera will receive a response with Approved status.
    *Note: Only when you have Auth Sum ≥ Debit Sum, then you’ll be able to proceed with completion.

Payments – Stand-Alone transactions 

A Sale/Stand-Alone transaction (TransType=01) can be made by Opera. This type of transaction isn’t dependent on any Authorizations made beforehand.
Flow:

  • A TransType=01 is sent (can be sent with or without a Token).

  • Belclient will open.

  • After proceeding with the transaction, a response will be received by Opera with Token + Auth Number of this single transaction.
    *Note: This is a Completed transaction. It won’t appear in the TransType=07 Step mentioned before.


Tokenization on-cloud & payments on-premise

When this is configured, the flow is somewhat similar with a key difference in tokenization.

  • The Payments flow stays the same. Review it here.

  • Tokenization process, when done on Cloud, has no middleman as the Belclient for entering the Credit Card details.

    1. The representatives in the hotel will enter the details on the Opera’s interface.

    2. A request will be sent directly to Pelecard’s Server with the details (The request’s body stays the same).

    3. A response will return to Opera’s Server and therefore to the representative’s interface.

Full on-cloud configuration

When this is configured, the connection will be made directly from Opera’s Server to Pelecard’s Servers, to do any action.

  • The Tokenization & Payments flows are without middleman. All requests will be sent directly.

  • All responses will be returned directly to Opera.

TransTypes – Basic Explanation of each Type

Basically, understanding the Types of requests may very much contribute to understanding the flow and finding a solution to many cases.

TransType=23 GetToken – Receive a Token for the Credit Card you entered.
TransType=01 Sale – Do an independent transaction, that doesn’t rely on Authorizations. The Credit Card will be charged at the end of process.
TransType=05 Authorization – Take a Hold of a specific amount on Credit Card, to be later charged with Completion(07).
TransType=06 Authorization – Same as 05↑
TransType=07 Authorization Completion – Mostly done on Check-Out, completing all authorizations (05↑ / 06↑) made before on this card.
TransType=25 GetToken Bulk – A request like 23↑, but with a bulk of Credit Cards and not just a single card.
TransType=25 GetPAN Bulk – A request for receiving a bulk of Credit Card PANs.
TransType=16 Reversal – Any authorization made in step 05 or 06, can be released by sending this request.
TransType=03 Refund – A refund request.

Key Points to Note

Auth Sum is lower than Debit Sum

When doing TransType=07 and the Sum of authorizations is less than the debit total, the window will appear differently:

  • Notice that the blue line is now Red.

    • If no authorization appears, that means you will have to make a full authorization on the whole amount sent, and then try this again.

    • If an authorization appears, that means you will only have to authorize the difference between authorized amount to debit amount.
      In the example above, you’ll have to do another 4₪ authorization to proceed.

Workstations 

While working with any interface, the WSNo (=Workstation, =PCName, =hostname, =desktop, etc..) is crucial. If a desktop is replaced and its’ PC name is changed, you won’t be able to work* on this desktop!
*On-Cloud you won’t be able to do such a thing, unless you re-configure the old PC’s Name on the new one, or return the old PC.
*On-Premise (or half on-Premise & half on-Cloud) you will be able to manually re-configure the PC Name to the current one. In some cases, not all processes will return to work, but you will still have a payment interface.
It is best advised to contact Pelecard before making such changes.

Common Issues

General Info / Troubleshooting:

 

  • Unable to Route Transaction = the workstation (<WSNo> in request) sent from Opera wasn’t found from the UIDs configured on the Admin interface.
  • On log file of the Service/OPI folder, you will get an ‘Perepheral data not found’ as seen in the picture above, with the workstation sent by Opera. You will have then to configure it instead of the UID previously configured.
  • Access to the path is denied = sometimes the administrator didn’t give enough permissions. This will be shown as follows in service log (picture).
  • Issuer or Switch Unavailable = error is shown in service log. Most likely the belclient on the given station is not activated.
  • Troubleshooting advice = whenever a client contacts for technical support, CHECK the service logs 1st. IF no logs are found that describe the issue occurring (or simply no logs were created at that time), the request was stopped on Opera’s side. Check that our client is working and request for a test transaction and direct the customer to Oracle for additional support. 
  •  if shown in tray, one or more of the directories configured in in/out and logs is missing.

  • PelecardOpiBridgeAdmin won’t open = most likely the configuration is wrong.
    Admin opens by locating the OpiMapping.xml that is in XML folder of the Service. Copy the path to the XML file (xml included). Then edit the PelecardOpiBridgeAdmin.exe.config file located in Admin folder and paste the path to the value on <appSettings>.