Supported Functions

Below is a list of supported functionalities of the interface to OPI.

Table 4-5 OPI - Supported Functions

Function	Description
Payment/Payment with Loyalty	EFTLink sends payment request to the OPI EPS. The OPI EPS will return a response message with formatted receipt strings for merchant and/or customer receipts. In an event of referral or communication failure where authorization cannot be obtained online then a prompt for authorization code will appear; authorization code must be obtained via telephone. After the manual authorization process is complete, a Sales Completion transaction is sent to finalize the original sale/purchase. In the event of a communication failure between EFTLink and the OPI EPS an initial Transaction Inquiry request is sent to the OPI EPS to determine if communication is back up. If communication is still down, the cashier must decide whether to retry or decline the transaction. In the event of a retry; a Transaction Inquiry message is sent and if a response is returned from the OPI EPS, the Transaction Inquiry response is used to finalize the sale/purchase. In the event of a decline, the OPI will initially attempt to reverse the transaction, however if communication is still down, the OPI will simply fail the transaction altogether and the POS will return to the tender selection screen.
Payment by Installments	The POS initiates a credit/debit tender, and the cashier is prompted as to whether the customer is paying by a Debit or Credit Card. If the customer is paying by Credit Card, the cashier will choose the number of installments to apply (if the customer decides to pay in installments). EFTLink receives the request from the POS and sends the payment request to the OPI EPS. The customer will proceed with the payment, and this will allow the customer to be able to spread out the cost of the purchase over a number of payments.
Payment by Card Token	EFTLink sends a payment request to the OPI EPS with the (Stored) card token value set in the request. The OPI EPS utilizes the card token value to process the sale without customer interaction required.
Payment by Quick Chip	EFTLink receives a Card Acquisition request from the POS at the start of the transaction. EFTLink sends this Card Acquisition request to the OPI EPS. This allows the customer to interact with the pin entry device while the POS operator can continue to ring items through the till. When the POS tenders’ credit/debit at the end of the transaction; EFTLink will send a payment request with the Card Acquisition details associated with the Card Acquisition at the beginning of the transaction. The OPI EPS will process the card details in the payment request without customer interaction required.
Check Payment	EFTLink sends payment request to the OPI EPS. The OPI EPS will return a response message with formatted receipt strings for merchant and/or customer receipts. The Transaction Inquiry scenario outlined in the Payment/Payment with Loyalty section also applies to this transaction type.
Refund	EFTLink sends refund requests to the OPI EPS. The OPI EPS will refund a transaction with the specified amount. The Transaction Inquiry scenario outlined in the Payment/Payment with Loyalty section also applies to this transaction type.
Refund with Card Token	EFTLink sends a refund request to the OPI EPS with the (Stored) card token value set in the request. The OPI EPS utilizes the card token value to process the refund without customer interaction required.
Reversal	EFTLink sends reversal requests to the OPI EPS. The OPI EPS will reverse a transaction specified by the original transaction reference. The Transaction Inquiry scenario outlined in the Payment/Payment with Loyalty section also applies to this transaction type.
Sale State Notifications	EFTLink sends line items through to the OPI EPS so that the customer display can be updated on the terminal in line with the POS.
Cancel Current Transaction	POS sends an abort request to EFTLink and if a transaction is cancellable, it is cancelled.
Read Non-PCI Card	EFTLink sends a card swipe request to the OPI EPS to receive data for non-pci cards. The full pan is returned in clear text, unencrypted and without tokenization. PCI cards will return a blank PAN.
Electronic Signature capture on PED	EFTLink sends a purchase, refund, svc payment, svc unload (cashout) or check authorization request to the OPI EPS. The signature can be captured on the pin entry device for the request provided and this signature will be confirmed by the POS operator and processed accordingly. The Transaction Inquiry scenario outlined in the Payment/Payment with Loyalty section also allows prompts for signature capture (if configured on the pin entry device). The Manual Authorization scenario outlined in the Payment/Payment with Loyalty section also allows prompts for signature capture (if configured on the pin entry device).
SVC Payment	EFTLink sends a gift or merchandise credit card payment request to the OPI EPS. If there are not enough funds available, only the funds available will be deducted. The POS client will have to settle the transaction with another tender in this scenario. The Transaction Inquiry scenario outlined in the Payment/Payment with Loyalty section also applies to this transaction type.
SVC Activate	EFTLink sends a gift or merchandise credit card activation request to the OPI EPS. The Transaction Inquiry scenario outlined in the Payment/Payment with Loyalty section also applies to this transaction type.
SVC Add Value	EFTLink sends a gift or merchandise credit card add value request to the OPI EPS. This will only add value to an account that has been activated. The Transaction Inquiry scenario outlined in the Payment/Payment with Loyalty section also applies to this transaction type.
SVC Balance Enquiry	EFTLink sends a gift or merchandise credit card balance enquiry request to the OPI EPS.
SVC Unload (Cashout)	EFTLink sends a gift or merchandise credit card cash out request to the OPI EPS. All funds are deducted from the account and the cash back amount is returned to the POS. The account is not deactivated as part of this process. The Transaction Inquiry scenario outlined in the Payment/Payment with Loyalty section also applies to this transaction type.
SVC Reversal	EFTLink sends a gift or merchandise credit card activate/add value/payment to the OPI EPS which is voided, or post voided and the original transaction actions are reversed. The Transaction Inquiry scenario outlined in the Payment/Payment with Loyalty section also applies to this transaction type.
Custom form for customer question/verification	EFTLink sends a request to the OPI EPS with a question/verification message. The customer selects either the Yes or No button. The core sends 'Y' or 'N' as part of the response to the POS.
Custom form for capturing phone number	EFTLink sends a request to the OPI EPS triggering a phone number capture. The customer keys in their phone number and selects submit. The core sends the captured phone number to the POS.
Custom form for capturing date	EFTLink sends a request to the OPI EPS to capture a date, for example a birth date. The customer keys in their birth date and selects submit. The core sends the captured date to the POS.
Custom form for signature capture	EFTLink sends a request to the OPI EPS to capture signature. The customer signs and selects Accept. The core sends the decoded signature to the POS.
Custom form for any alphanumeric data capture	EFTLink sends a request to the OPI EPS to capture any data which could be alphanumeric. A prompt is displayed regarding the type of data expected. The customer keys in the relevant data and selects submit. The core sends the data back to the POS.
Custom form for a survey or donation selection	EFTLink sends a request to the OPI EPS to capture data in the form of either buttons or radio buttons. The customer can choose between a list of buttons or radio buttons which have different responses or amounts and selects submit. The core sends the value of the button pressed back to the POS.
Custom form for displaying a message	EFTLink sends a request to the OPI EPS to display a message to the customer. The message times out after a configurable amount of time.
Custom form for displaying a scannable QR code	EFTLink sends a request to the OPI EPS to display a scannable QR code to the customer. The message times out after a configurable amount of time.
E-Wallet payments for example, WeChat Pay and AliPay	Flow 1 - Customer initiated transaction via E-Wallet button press on the PED. EFTLink sends a standard sale/purchase request to the OPI EPS. The customer selects the button to pay via their E-Wallet (as opposed to the usual chip and pin, swipe and other card payment methods) on the PED. The OPI EPS returns a response containing the E-Wallet data. EFTLink feeds this data back to the POS to complete the transaction. Flow 2 - Cashier initiated transaction via E-Wallet tenders on the POS. POS tenders to pay the transaction via E-Wallet tender. EFTLink sends a sale/purchase message to the OPI EPS, specifying that the PaymentMethod is E-Wallet. The OPI EPS displays a QR code which the customer scans with their E-Wallet device (typically a mobile phone). The transaction is confirmed on the OPI EPS and the WalletAuthorizationData is returned via EFTLink to the POS to complete the transaction. Flow 3 - Cashier initiated transaction via E-Wallet tenders on the POS - Customer QR code scanned on the POS. POS tenders to pay the transaction via E-Wallet tender. Cashier scans customer's E-Wallet QR code. EFTLink sends a sale/purchase message to the OPI EPS, specifying that the PaymentMethod is E-Wallet and the WalletId of the customer's E-Wallet. The transaction is confirmed on the OPI EPS and the WalletAuthorizationData is returned via EFTLink to the POS to complete the transaction.
Two-stage payments for example, tax-free shopping	EFTLink sends a Card Acquisition request to the OPI EPS prior to a sale/purchase request. The OPI EPS reads the customer's card details and responds with the BIN range and Country Code of the customer's card to determine (on the POS) whether this customer is eligible for tax free shopping. If so, the POS processes the tax-free refund and modifies the total transaction amount with the tax removed and sends the new amount to EFTLink. EFTLink sends a sale/purchase request with the new modified amount and the original transaction reference to the OPI EPS. The OPI EPS looks up the original card details from the transaction reference and charges the card with the modified amount to complete the transaction.
Invoice payments	The POS adds a non-merch item “Invoice Payment” which initiates an Invoice Payment transaction. The cashier is prompted as to whether the customer would like to pay by “Cash” or “Card” (If configured). The cashier is further prompted to “Please scan the invoice barcode”. The cashier may key or scan the invoice barcode. EFTLink receives the request from the POS and sends the “Invoice Payment” request to the OPI EPS. The customer will proceed with the payment at this point. If the customer selected to pay by “Cash” during the initial prompt on the POS, the OPI EPS will simply clear the invoice as paid and send back the successful response. The following prompts are skippable: 1. The customer will input on the PED the amount of the invoice they would like to pay in whichever currency the PED is configured. If the customer selected to pay by “Card” during the initial prompt on the POS, the PED will prompt as to whether or not the customer would like to pay by “Cash”, “Credit” or “Debit”. The customer may choose how to pay at this point. If the customer selects “Cash”, the invoice will be cleared as paid. If the customer selects “Credit” or “Debit” card, the usual steps will take place for a typical Card transaction. Invoice payments are not reversible at this time. However, if a card payment was made, the cashier may choose to reverse as a standard card payment. It is assumed that the merchant will have the necessary measures in place to avoid issues with “Cash” payments (in terms of a customer not having enough cash to pay for the transaction and so on). The Transaction Inquiry scenario outlined in the Payment/Payment with Loyalty section also applies to this transaction type. .
Cell phone recharge (Top-up)	The POS adds a non-merch item “Cell Phone Recharge” which initiates a Cell Phone Recharge transaction. The cashier is prompted as to whether the customer would like to pay by “Cash” or “Card” (If configured). EFTLink receives the request from the POS and sends the “Cell Phone Recharge” request to the OPI EPS. The customer will proceed with the payment at this point. If the customer selected to pay by “Cash” during the initial prompt on the POS, the OPI EPS will simply clear the invoice as paid and send back the successful response. The following prompts are skippable: 1. The customer will be prompted by the PED to select which Service Provider they are with. 2. The customer will be prompted to select a RechargeAmount which they would like to recharge (top-up) their phone by. 3. The customer will be prompted by the PED to input their phone number. If the customer selected to pay by “Card” during the initial prompt on the POS, the PED will prompt as to whether the customer would like to pay by “Cash”, “Credit” or “Debit”. The customer may choose how to pay at this point. If the customer selects “Cash”, the invoice will be cleared as paid. If the customer selects “Credit” or “Debit” card, the usual steps will take place for a typical Card transaction. Cell phone recharge payments are not reversible. However, if a card payment was made, the cashier may choose to reverse as a standard card payment. It is assumed that the merchant will have the necessary measures in place to avoid issues with “Cash” payments (in terms of a customer not having enough cash to pay for the transaction and so on). The Transaction Inquiry scenario outlined in the Payment/Payment with Loyalty section also applies to this transaction type.
PLCC (Private Label Credit Cards)	Support for PLCC has been added to the OPI core. PLCC Account Lookup – this is used to look up the account details for a PLCC. This includes the credit balance and remaining credit, and the card token in addition to cardholder information. This can be used to check the balance of the card prior to performing an account payment or tender transaction. The PLCC can be presented to the PED. If the PLCC token is saved against the customer, the saved card token can be used in CNP scenarios. PLCC Payment On Account – this transaction type can be used to make a payment against the balance on the PLCC. The payment transaction can be initiated by the POS and can usually include most types of tender except Credit cards. Some tenders such as Debit cards would be processed by the PED. This would usually be proceeded by an Account Lookup to determine the outstanding balance. PLCC Application Request – this is used to perform a new PLCC application request. Some of the required detail is collected on the POS and sent to EFTLink within the request message, but the PED may also collect some data directly from the applicant. Note that PLCC application process and data is very dependent on the PSP and the finance company offering the PLCC, and may require custom extensions on the POS. Tender by PLCC – In order to allow the POS to tender explicitly by PLCC, a new eWallet Payment Method “61” “PLCC” has been added, which the POS can set on the Sale/Purchase request message, instructing the PED to only allow tender by PLCC. Tender by Debit card – Since PLCC Payment On Account cannot be tendered by credit card, a new eWallet PaymentMethod “62” “Debit Card” has been added, allowing the POS to instruct the PED to only allow tender by Debit Card.
Card Acquisition	Support for card acquisition has been added to the OPI core. The OPI core will now accept an explicit card acquisition request from the POS. the customer will be prompted to present their payment card to the PED so the details of their card (tokens) can be pre-read. This can be useful in several scenarios such as looking up the sales transactions that used that same card, when shopper requests to return items, but does not have the original receipt, thus allowing for a referenced refund, rather than an un-referenced (blind) refund. The following fields are returned to the POS (as determined by PSP) none of which are in scope of PCI DSS - CardAlias, CustomerId, CardHolderEmail, CardToken.
Pre-authorization transactions	Support for card pre-authorization transactions has been added to the OPI core. Authorization Transaction – this message type can be used to request an authorization for funds (without capture/settlement). This can be used for gaining authorization for POS transactions that are not being immediately picked up or delivered to a customer, such as pre-sales and so on, and can be for either payment cards presented to the PED, or with a saved Card Token. The POS can then request completion (capture) of the authorization when the goods are picked up or dispatched, using the Sales Completion transaction. Authorization Release Transaction – this message can be used to release or cancel an existing authorization. Top-UpAuthorization Transaction – this message can be used to increase the amount of an existing authorization. It is possible that multiple authorizations are performed during the lifecycle of a POS transaction or order.
PED Status Messages	Support for PED status messages have been added to the OPI core. The OPI core has configurations that can be enabled, that will instruct EFTLink to connect to an endpoint running on the OPI implementation to establish a websocket channel, and will be listening on this websocket, for Terminal Status messages during the TransactionRequest operation. This is a “fire and forget” message sent from the PED to the POS, and there is no response message. These messages would usually be the same/similar as those messages that are displayed on the PED to instruct/inform the shopper, for example to remove their card.
PSP Cloud Host Endpoint	Support for a cloud host endpoint has been added to the OPI core. This allows a PSP to offer their OPI implementation in the cloud, rather than locally, on-premises. In order to enable this all Retail OPI request messages have a new field, RequestTerminalId, which allows the PSP OPI implementation to route the transaction to the appropriate PED.
Payment Query	Support for Payment Query has been added to the OPI core. The OPI Retail core supports a PaymentQuery request message. This allows the POS to send this message to query the status of the last payment request message. The OPI Retail core supports a PaymentQuery request message.
PSPPaymentBrand for the CardCircuit	The OPI Retail core allows the PSPPaymentBrand field to be returned directly to the POS in the CardCircuit response field (Xstore POS uses the CardCircuit attribute to map to a tender). Currently the IssuerID returned by the OPI payment partner is used via the CardRange.xml file to determine the value of the CardCircuit attribute. However, some payment types such as eWallets do not have a specific IssuerID, meaning that either a generic IssuerID is used, or one of the “Reserve-XX” needs to be configured. This feature is enabled via the OPI Retail configuration value, UsePspPaymentBrandForCardCircuit.
Reference Refund Enhancements	The OPI Retail core now has the capability to include the OPI partner name in the validation that it performs to prevent referenced refunds being sent to different OPI implementations. The EPSName property will be appended to the PaymentProviderName returned to the POS. When the referenced refund transaction is attempted, EFTLink will check that the OPI implementation in use has the same EPSName as the one specified in the reference refund request data.
Card Acquisition Enhancements	The OPI Retail core has added three new fields to the response data sent to the POS following a CardAcquisition request: FundingSourceType, PSPPaymentBrand and PSPPaymentVariant. The POS can then use these fields in the request date sent to tax free shopping providers.