Integration features

A number of the below terminal features will need to be configured via mx51. If you would like a feature enabled on your test terminal please direct this request to your mx51 contact.

Mandatory Feature Set

Pairing & unpairing: This is the creation of a set of shared encryption secrets between the POS and the EFTPOS terminal, and it’s required before any other communication can take place. The process needs to be triggered on both the POS and EFTPOS terminal to begin and requires the user to accept a matching code on both devices to complete the pairing process. Unpairing is the dropping of these secrets.

Automatic Address resolution: Automatic EFTPOS Address Resolution is an optional configuration in your POS’s EFTPOS Settings screen. When turned on, the client library will automatically try to resolve the address of the EFTPOS based on the supplied Serial-Number.

For more information see here.

Purchase & refund: A positive/negative transaction driven from the POS to the EFTPOS terminal. This includes displaying errors to the user and POS based signature acceptance/decline functionality.

Mail Order & Telephone Order (MOTO): This is a card not present transaction used when a customer’s card is not physically available to a merchant to complete a transaction. The POS must flag a transaction as MOTO and the card details of the customer must be entered manually into the EFTPOS terminal.

Terminal based tipping (Hospitality Only): This feature allows tips entered into the EFTPOS terminal once a purchase request has been sent from the POS. The POS is required to accept the additional tipping field in the response back from the EFTPOS terminal.

Terminal based surcharging: This feature automatically adds a predefined surcharge to a purchase transaction at the time the card is presented to the terminal. The POS is required to accept the surcharging field in the response back from the EFTPOS terminal.

Storing and Printing of Merchant Receipts: The requirement is for POS to store and have the ability to reprint Merchant EFTPOS receipts for all successful transactions. Storing and Reprinting of EFTPOS receipts will be used for reconciliation, merchant and/or customer purposes.

Integrated printing: The EFTPOS terminal relies on the POS to print receipts and settlement reports from the POS printer.

Transaction recovery: In the event of a network dropout during a transaction, the POS needs to attempt to retrieve the outcome of the last transaction when it reconnects. The POS then needs to update the open sale with the outcome provided by the library. In the event that the POS cannot determine the outcome of a transaction (network failure), the POS needs to allow the user the option to "override as paid" if they’re certain the transaction was successful.

Settlement: A request driven by the POS to settle the EFTPOS terminal. A settlement is an instruction by the EFTPOS terminal to the bank to finish its day's trading. The merchant will receive all funds prior to the settlement instruction in the next deposit. The POS has the option to store the settlement information for reconciliation.

Key Rolling: When the POS and the terminal are paired they will automatically re-calculate the security keys roughly every two weeks. The POS needs to successfully receive and store these security keys to maintain paring. Key rolling can be triggered manually via the Enter + 3 menu on the EFTPOS terminal.

Logging: Vital part of the integration to assist in development and production for our merchants. Logging is required for our support team to investigate further issues during development and in production.

Additional Feature Set

Terminal based Printing: The EFTPOS terminal will be responsible for printing the EFTPOS receipts from the EFTPOS printer if using a vx690 terminal.

POS based tipping: This feature allows tips entered into the POS to be included with the purchase request to the EFTPOS terminal.

POS based Surcharging: * In previous library versions, when sending surcharge amounts from the POS to the eftpos terminal, the surcharge amount was included in the total purchase amount. POS vendors will now have the ability to separate this into a seperate surcharge amount when sending a purchase request to the eftpos terminal.

POS based Cashout: Cashout is a transaction type that requests funds from the customer's bank to be withdrawn and then those funds are to be provided by the merchant. Cashout is a unique transaction type and needs to be implemented independently of a purchase transaction. This feature allows the merchant to enter the Cashout amount into the POS and then request a cashout transaction for that total to the EFTPOS terminal. Note: Cashout is only available when selecting Savings or Cheque.

POS based Purchase with cashout: This transaction type combines a purchase and a cashout transaction into a single request. It is used when a customer requests to withdraw funds from the merchant while completing a purchase. The Cashout amount is entered into the POS along with the purchase. Cashout with purchase is a unique transaction type and needs to be implemented independently of purchase and cashout. Note: Cashout is only available when selecting Savings or Cheque.

Terminal based Purchase with cashout: This feature asks the cardholder to enter their desired cashout amount into the EFTPOS terminal at the time of completing a purchase. The POS is required to accept the additional cashout field in the response back from the EFTPOS terminal. Note: Cashout is only available when selecting Savings or Cheque.

Settlement Enquiry: This feature is a request to the terminal to return the current or a previous dates settlement report. It allows the POS to request a settlement report from the EFTPOS terminal without requiring a settlement. The request will trigger the terminal to prompt the merchant to select the current day or another date and then return the report to the POS.

Get Last Transaction: A feature that gives the user the option to ask the EFTPOS terminal the outcome of the last transaction, which can include printing the receipt.

Ability to suppress Merchant Password from POS for refund and MOTO: * This feature give POS vendors the ability to handle the secure merchant password prompt on the POS instead of the EFTPOS terminal. Given the security check is already done on the POS, the EFTPOS terminal will directly access refunds or MOTO.

Split Transactions: This involves splitting the payment amount into two or more transactions made by different payment methods. For example, you could split a purchase or refund so that it is partially for paid with cash and use EFTPOS to pay the remaining amount. Or split the EFTPOS purchase or refund to use two different credit cards.

Pre-Authorisation: This feature is a set of requests that manage the authorisation from a customer to the merchant to debit the customer’s card in future. It is used in situations where the future cost of goods and services are unknown or as security/deposit for goods and services currently being provided. Examples include bar tabs, hotel check-ins and vehicle rental. More information on this feature is available here.

Pay at Table: This feature is designed for hospitality dining environments but can be implemented for other uses. Pay at Table changes the integration model by allowing the EFTPOS terminal to initiate a transaction. When Pay at Table is initiated on the EFTPOS terminal it will send a request to the POS to return a table total or held sale. The cardholder can then complete payment on the EFTPOS terminal and once completed the EFTPOS terminal will update the POS to close the table or sale. For detailed information on Pay at Table please see the feature page here.