Integration Checklist

In order to successfully complete the integration, it is expected that all of the below items have been implemented. Please note that the PAC and PAT integrations function in different ways (as described under "What is Connect?") and are intended to be completed separately.

General

Every integration should implement these:

  • Host and API Key Configuration - Ability to configure the Host and API Key values for each till.
  • Reports - Ability to store at least End of Day reports on the POS. It is mandatory for the POS to implement EOD reporting, and at a minimum, store a digital copy of each report in case it is needed in the future. End of Day reports are crucial because they trigger any pending settlements, which means that any payment data stored in a PDQ gets sent to the acquirer. In addition, the data contained within them aids with reconciliation, and so should totals fall out of sync between the POS and a PDQ, the report is available to describe the true PDQ totals. Hence, they are considered a fundamental part of integrations with Connect. How reporting is implemented will vary between PAC and PAT, so each is further described in the relevant sections below.

PAC

If you are developing a PAC integration, you should implement the following:

  • Terminal Choice - Ability to choose which terminal to use for either each transaction or each till. REST | WebSockets
  • Transactions - Ability to initiate both SALE and REFUND transactions. REST | WebSockets
  • Transaction Notifications - Transaction notifications should be displayed on the POS while a transaction is in progress. REST | WebSockets
  • Signature Verification - When signature verification is required, there should be a prompt on the POS asking the user to check if the signature on the receipt matches the signature on the card. REST | WebSockets
  • Cancelling Transactions - Ability to cancel a transaction from the POS. REST | WebSockets
  • Transaction Results - All possible transaction results should be dealt with appropriately:
    • SUCCESSFUL - Transaction was successful. The amount should clear off the POS.
    • DECLINED, VOID or UNSUCCESSFUL - Transaction was not successful and no payment has been taken. The POS should inform the user as to the outcome and the amount should not clear off the POS.
    • CANCELLED - Transaction was cancelled and no payment has been taken. The POS should inform the user as to the outcome and the amount should not clear off the POS.
    • TIMED_OUT - Transaction has timed out and payment may or may not have been taken. A procedure that triggers this scenario can be found in the invoking scenarios section. It is recommended that you check if the terminal is still available:
      • AVAILABLE - Prompt the user to manually check if the transaction was successful and record this on the POS if it was. Alternatively, request a duplicate of the last transaction and check if this matches the original transaction.
      • BUSY or not listed - Display an error message advising the user to check the PDQ cables and network connection etc. For example: "Please check that the PDQ is idle and no action is prompted on its screen, that its network and power cables are correctly connected and that it is not in Standalone Mode. Finally, restart the PDQ and, if the problem persists, please contact support." If the implementation is based upon REST, please see the built-in user messages section.
  • Cashback - When Cashback is added to a transaction, this should be recorded on the POS. If this is not implemented, we will not be able to offer Cashback to any of your merchants.
  • Gratuity - When Gratuity is added to a transaction, this should be recorded on the POS. If this is not implemented, we will not be able to offer Gratuity to any of your merchants.
  • Reports - In PAC integrations, PDQ reports must be initiated through the POS, and the POS must handle the result of the report appropriately. See the general section above for information about handling reports. REST | WebSockets
    The possible PDQ reports are:
    • End of Day
    • Banking (optional)
    • X Balance (optional)
    • Z Balance (optional)

PAT

If you are developing a PAT integration, you should implement the following:

  • Table List - Ability to access a listing of all currently open tables from the PDQ. REST | WebSockets
  • Table Lock - Ability to lock an open table on the PDQ. REST | WebSockets
  • EPoS Receipt - Ability to print a receipt set by the EPoS. REST | WebSockets
  • Table Payments - Ability to deal with multiple (card and OTHER) payments on a table, including those with gratuity.
  • Reports - In PAT integrations, PDQ End of Day reports are initiated on the PDQ and then made available to the POS via the currently connected interface (REST or WS). Please see the general section above for information about handling the report. REST | WebSockets

Next Steps

Once you have completed all of the items on the checklist, you will be ready to enter our QA Process.