For your SPI integration to be certified by our team, it must satisfy these mandatory requirements. There are also some additional features that you may choose to add.

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.


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.