Integration Checklist

Every integration should implement these:

• Host and API Key Configuration - Ability to configure the Host and API Key values for each till.

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)

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