Requirements

General requirements

G1	The correct Tenant code (`tenantCode`), POS vendor ID (`posVendorId`), and POS version (`posVersion`) is passed to SPI. Learn more The POS version is incremented each time you release an update.

Pairing requirements

P1	The POS can be paired with the EFTPOS terminal as well as unpaired.
P2	The user interface includes a form for pairing with an EFTPOS terminal. It has the following fields. An input field for the POS ID. An input field for the EFTPOS serial number. In the test environment only: a button to enable ‘test mode’. A button to submit the form.
P3	When paired and connected, the IP address of the connected EFTPOS terminal cannot be changed.
P4	When paired and connected, if a network disconnection occurs, the displayed connection status changes to “Paired but trying to connect”. When this status is displayed, the following are possible. The IP address can be changed. ‘Test mode’ can be disabled.
P5	The ‘pairing secrets’ are not visible to the merchant at any time, including when pairing, unpairing, and rolling the keys.
P6	The pairing details are stored so that if the POS or EFTPOS terminal restart, the connection can be restored. They must be stored in an encrypted and secure way.
P7	When restarting the integration, the pairing secrets are retrieved from the EFTPOS terminal.
P8	The POS can be paired with one EFTPOS terminal (one-to-one pairing). Optionally, you can support multi-pairing.
P9	When the EFTPOS terminal performs ‘key rolling’, the POS participates by also rolling its keys.
P10	Browser-based POSs only: there is an option to automatically find the IP address of the EFTPOS terminal.

Transaction requirements

T1	The following types of transactions are supported: purchases, refunds, and MOTO payments.
T2	The `posRefId` of each transaction request is unique. When retrying a transaction (e.g. after an invalid PIN), the same `posRefId` is not used.
T3	It is possible to cancel a transaction from the POS.
T4	Both the merchant and customer EFTPOS receipts are either: printed during the transaction, and/or stored and able to be printed at a later time. Learn more
T5	For transactions that require a signature, the POS prompts the merchant to accept or decline the signature.
T6	For transactions that require a signature, the ‘receipt to sign’ is printed.
T7	For transactions that require a signature: if the receipt is approved, the sale is closed; otherwise, if the receipt is declined, the sale remains open. Learn more
T8	When a transaction is declined (e.g. due to an invalid PIN), the sale remains open.
T9	When a network disconnection interrupts a transaction, the transaction is recovered automatically, or, if that is not possible, manually.

Settlement requirements

S1	A settlement can be performed from the POS.

Logging requirements

L1	All SPI events are logged. Learn more

Recommended features

These features are not required for certification but they are recommended for the benefits they provide.

Lock POS UI during a transaction (Optional)	When a transaction request is made, the POS’s user interface is locked against interaction until the response is returned. (This prevents issues caused by the merchant editing the sale or leaving the page during a transaction.)
Configurable port number (Optional)	SPI’s port number can be changed in the settings. (This allows your integration to be used on a network in which port 8282 is already in use.)
Manual override label (Optional)	Transactions that have been manually overridden can be identified as such during reconciliation. (This allows these transactions to be audited for human error.)

📘
Reconciliation is when a merchant checks that their sales records (i.e. their merchant receipts) match their bank statements.

Additional features

Beyond these basic features, there are a variety of additional, optional features that you can include in your integration — MOTO, Pay at table, Pre-authorisation, and more.