POS Vendor Terms and Conditions

Your products and services are subject to Linkly’s terms and conditions.

Please read these sections and note that they are agreed and understood.

  • The POS user interface to EFTPOS must be acceptable to customers.
  • The refund operation should be protected on the POS to prohibit unauthorised use.
  • The Linkly system will store journal and receipt files on the POS hard-drive. These require minimal space and can be deleted after an appropriate period (e.g. 3 months).
  • The documentation for the Linkly system must be read. This includes the hardware and software installation.
  • The development PIN pad uses the cents amount as the response code. The live system will not do this.
  • The POS operator has access to EFTPOS logon and reprint receipt functions, either via the Linkly Control Panel or directly via the POS interface.

Linkly Cloud

This section is only relevant to POS systems using the Linkly Cloud interface. You agree and comply to the following:

  • Perform a $10.00 transaction. The POS displays all LINKLY dialog messages correctly.
  • Perform a $10.00 transaction. The POS sends a cancel key to LINKLY when it is enabled by the display event and the operator selects cancel.
  • It is understood the LINKLY Cloud will not be accessible if a reliable Internet connection is not available from the POS site.
  • The POS must always connect to pos.cloud.pceftpos.com using port 443 and validate the server certificate chain.
  • The POS must support server certificates used by the Linkly Cloud. The current X.509 certificate uses SAN and has an RSA 2048 bit public/private keypair as well as an SHA256 signature hash algorithm. Current certificate authorities in use are: Let’s Encrypt and DigiCert.
  • The POS must support encryption used by the Linkly Cloud. Currently TLS1.2 and SNI support required, using one of the available ciphers:
    • TLS_RSA_WITH_AES_128_CBC_SHA
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
    • TLS_RSA_WITH_AES_128_CBC_SHA256
    • TLS_RSA_WITH_AES_128_GCM_SHA256
    • TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256
    • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256
    • TLS_RSA_WITH_AES_256_CBC_SHA
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA
    • TLS_RSA_WITH_AES_256_CBC_SHA256
    • TLS_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384
    • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
    • TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256
  • It is understood the POS may be required to make changes to the interface if the bank deems that there is a security risk (e.g. updating from TLS1.2 to a future protocol).
  • The POS must resolve the DNS entry for pos.cloud.pceftpos.com for each connection attempt. The DNS address may change between attempts.
  • The DNS used by the POS honours TTL.
  • The username, password and PIN pad pair code should be reasonably secure. They are required when you pair a new PIN pad.
  • The POS opens a session for each sale and then closes the session at the end of the sale, or the POS implements TCP KeepAlive messages to ensure the session stays active.


Required Information

Important Information; Please read carefully for instructions on how to complete the accreditation script.


How to complete:

To complete the accreditation scripts on the following page, perform a transaction as detailed within the instruction for each test case.

Use the text box accompanying each test to include the TXN Reference & the Time/Date each transaction was performed. Please note: A TXN Reference is a specific property sent by the POS and should not be confused with the session ID associated with the request if you are using our cloud interface.

Once you have completed each set of test cases, attach the EFTPOS.LOG file found within the local directory of the PC (On-Prem) or contact [email protected] with the Cloud ID (For Cloud customers) to have the log attached to the script by one of our staff. This log is used to determine that each transaction performed is formatted correctly, and is required.

For On-Prem integrations, the log is found in the below directory:

  • C:\Program Files(x86)\PC_EFT\EFTPOS.LOG
  • C:\Program Files(x86)\PC_EFT\EFTPOS000.LOG

Submitting a test script without attaching the correct log file will result in the submission not being approved.


Before you begin:

The accreditation scripts contained on the following page assume familiarity with the Linkly APIs, and the requirements for each transaction set that is intended to be implemented.

In addition to this, each feature set requires the addition of Purchase Analysis Data (PAD), a variable set by the POS and returned by the Client at the completion of a transaction containing additional data.

PAD Tags are detailed within Appendix C in each set of API documents.

Note: Linkly strongly encourages targeting Windows 7 or higher as your Windows POS Operating System. If you use Windows XP or lower, please contact the Linkly POS Integrations team first to discuss feasibility, as Windows XP is no longer supported.


Basket Data

The Linkly Core Payments API contains a Basket Data function to facilitate third party integrations without additional development.

There are two ways a POS may interact with the basket data:

  • Call Linkly as each item is scanned (adding / updating / removing items as necessary).
  • Call the basket command once, with the full basket, before calling transaction.

Only one is mandatory. Leave a note in the field provided if you choose not to support both.


Helpful Links

Depending on your submission type, optional and required features are documented here:

Important Note: Not all features are available for each acquirer. Some implementations are terminal dependent. Please contact [email protected] for more information.