The PAC API supports one or more simultaneous WebSocket connections to drive one or more terminals. This is to allow for multiple EPoS systems to interact with the same pool of terminals.

The PAT API can only interact with one WebSocket connection at a time. This ensures an integrating EPoS system has only one point of entry for requests from terminals. Should multiple connections be made, the last to connect will be the one to receive terminal requests with the other connections being discontinued (see the "Connection Discontinued" error message for more details).

Useful for when it is unknown which terminals are connected (e.g. when deciding to which terminal to send a transaction).

Useful for when it is unknown which terminals are connected or when searching for a terminal that can handle a specific request.

N/A

Identical to a "Terminals Details" Response.

Similar to a "Connected Terminals" request except this request returns details for a specific terminal. Useful if trying to find out the status of a specific terminal.

Similar to a "Connected Terminals" request except this request requires a list of TPIs for which the EPoS is requesting details. Useful for when the connected terminals are already known or if trying to find out the status of a specific terminal(s).

N/A

Identical to a "Connected Terminals" Response.

While this request is being processed other requests and notifications could be sent to Connect or to the EPoS, these include:

• Connect will send notifications about the current state of the transaction via the Terminal Notification message.
• The EPoS can request for the transaction to be cancelled via the Cancel Transaction request message.
  Please note there are restrictions on when this request will be successful, and both this perform transaction request and the cancel request will receive responses.
• The transaction could require a customer signature to be verified by the EPoS. In this case, Connect will send a Signature Verification request to the EPoS asking if the signature has been accepted. Processing of this transaction will pause until the signature verification request has been responded to or until it times out.

For a summary of how this request can flow, please see the Websocket PAC Transaction Flow.

While this request is being processed other requests and notifications could be sent to Connect or to the EPoS, these include:

• Connect will send notifications about the current state of the transaction via the Terminal Notification message.
• The EPoS can request for the transaction to be cancelled via the Cancel Transaction request message.
  Please note there are restrictions on when this request will be successful, and both this perform transaction request and the cancel request will receive responses.
• The transaction could require a customer signature to be verified by the EPoS. In this case, Connect will send a Signature Verification request to the EPoS asking if the signature has been accepted. Processing of this transaction will pause until the signature verification request has been responded to or until it times out.

For a summary of how this request can flow, please see the Websocket PAC Transaction Flow.

While this request is being processed other requests and notifications could be sent to Connect or to the EPoS, these include:

• Connect will send notifications about the current state of the transaction via the Terminal Notification message.
• The EPoS can request for the transaction to be cancelled via the Cancel Transaction request message.
  Please note there are restrictions on when this request will be successful, and both this perform transaction request and the cancel request will receive responses.
• The transaction could require a customer signature to be verified by the EPoS. In this case, Connect will send a Signature Verification request to the EPoS asking if the signature has been accepted. Processing of this transaction will pause until the signature verification request has been responded to or until it times out.

For a summary of how this request can flow, please see the Websocket PAC Transaction Flow.

The 'transactionResult' property in this message is what should be actioned to determine the result of this transaction request.

In the case of a response having a 'transactionResult' value of 'TIMED_OUT', it will be unknown to the EPoS if the transaction was successful or unsuccessful. To accommodate for this exceptional circumstance we recommend the EPoS has the ability to manually record the payment in case the actual result of the transaction was successful.

All receipts by default are printed on the terminal even when they are returned to the EPoS.

The number and type of receipts provided can differ depending on what receipts the terminal generates. Due to this, we recommend not relying on any information contained within the 'receiptLines' property, only store and/or print the receipt(s). Examples of receipt behaviour include:

• A chip and pin transaction will provide a Merchant and Customer copy.
• A contactless transaction will provide only a Merchant copy by default.
• A transaction that has been cancelled using a cancel request will provide no receipts.

Please see the Configuration Options page for more information about terminal receipt printing options and contactless Customer receipt options.

If transaction information (including a duplicate receipt) is required again and no new transactions have already taken place on the terminal, a Duplicate request can be made to get this information.

For a summary of how we recommend this perform transaction response is handled by the EPoS, please see the Websocket PAC Transaction Flow.

The 'transactionResult' property in this message is what should be actioned to determine the result of this transaction request.

In the case of a response having a 'transactionResult' value of 'TIMED_OUT', it will be unknown to the EPoS if the transaction was successful or unsuccessful. To accommodate for this exceptional circumstance we recommend the EPoS has the ability to manually record the payment in case the actual result of the transaction was successful.

All receipts by default are printed on the terminal even when they are returned to the EPoS.

The number and type of receipts provided can differ depending on what receipts the terminal generates. Due to this, we recommend not relying on any information contained within the 'receiptLines' property, only store and/or print the receipt(s). Examples of receipt behaviour include:

• A chip and pin transaction will provide a Merchant and Customer copy.
• A contactless transaction will provide only a Merchant copy by default.
• A transaction that has been cancelled using a cancel request will provide no receipts.

Please see the Configuration Options page for more information about terminal receipt printing options and contactless Customer receipt options.

If transaction information (including a duplicate receipt) is required again and no new transactions have already taken place on the terminal, a Duplicate request can be made to get this information.

For a summary of how we recommend this perform transaction response is handled by the EPoS, please see the Websocket PAC Transaction Flow.

A transaction can also be cancelled using the 'Cancel' button on the terminal. There are situations where the cancel button on the terminal can cancel a transaction but this cancel request will fail - this is dependent on terminal type.

A transaction can also be cancelled using the 'Cancel' button on the terminal. There are situations where the cancel button on the terminal can cancel a transaction but this cancel request will fail - this is dependent on terminal type.

N/A

If the cancel request was successful then the Perform Transaction request will also receive a response.

The reports a terminal can complete are:

• reportXBalance:
  Represents an X-Balance report. An X Balance report returns the current local session totals on the PDQ without resetting them.
• reportZBalance:
  Represents a Z-Balance report. A Z Balance report returns the current local session totals on the PDQ and resets them. Other than the reset of totals, a Z-Balance Report is the same as an X-Balance report.
• reportBanking:
  Represents a Banking report for all Acquirers. A Banking report fetches the current banking totals from the bank and returns these totals. The banking totals are reset in line with banking times.
• reportEndOfDay:
  Represents an End of Day report for all Acquirers. An EOD report performs a Z-Balance report followed by a Banking report.

The reports a terminal can complete are:

• reportXBalance:
  Represents an X-Balance report. An X Balance report returns the current local session totals on the PDQ without resetting them.
• reportZBalance:
  Represents a Z-Balance report. A Z Balance report returns the current local session totals on the PDQ and resets them. Other than the reset of totals, a Z-Balance Report is the same as an X-Balance report.
• reportBanking:
  Represents a Banking report for all Acquirers. A Banking report fetches the current banking totals from the bank and returns these totals. The banking totals are reset in line with banking times.
• reportEndOfDay:
  Represents an End of Day report for all Acquirers. An EOD report performs a Z-Balance report followed by a Banking report.

We recommend this information is stored or printed for the purposes of reconciliation.

We recommend this information is stored or printed for the purposes of reconciliation.

If the terminal's printer is enabled, it will print the Duplicate Customer receipt.

If the terminal's printer is enabled, it will print the Duplicate Customer receipt.

N/A

N/A

The terminal will remain in a 'BUSY' state until this request is replied to / times out, and until the transaction this request applies to has provided a response.

If the terminal's printer is disabled, the receipt in this request should be printed for the customer to sign and for the merchant to verify. This receipt should then be kept by the merchant as proof of sale. We recommend not relying on any information contained within the 'receiptLines' property, only print the receipt.

A final customer receipt (and a final merchant receipt in the case of signature non-acceptance) will be provided in the Perform Transaction response.

The terminal will remain in a 'BUSY' state until this request is replied to / times out, and until the transaction this request applies to has provided a response.

If the terminal's printer is disabled, the receipt in this request should be printed for the customer to sign and for the merchant to verify. This receipt should then be kept by the merchant as proof of sale. We recommend not relying on any information contained within the 'receiptLines' property, only print the receipt.

A final customer receipt (and a final merchant receipt in the case of signature non-acceptance) will be provided in the Perform Transaction response.

If an accepted response is provided a Perform Transaction response should shortly be received.

If a not accepted response is provided the terminal will attempt to reverse the transaction and a final response will be provided in the Perform Transaction response.

If an accepted response is provided a Perform Transaction response should shortly be received.

If a not accepted response is provided the terminal will attempt to reverse the transaction and a final response will be provided in the Perform Transaction response.

Terminal notifications are provided to be displayed on an EPoS, so the user can be informed of the current state of a transaction on a terminal.

The only way we recommend relying on these notifications other than to be displayed is for the enabling/disabling of the EPoS users ability to send a Cancel Transaction request.

Terminal notifications are provided to be displayed on an EPoS, so the user can be informed of the current state of a transaction on a terminal.

The only way we recommend relying on these notifications other than to be displayed is for the enabling/disabling of the EPoS users ability to send a Cancel Transaction request.

Please note not all error messages are sent in reply to a request, so the 'id' element may be excluded.

A table of error message codes is below:

Message	Error Code	Description
Parse Error	-32700	Invalid JSON was received by the server. An error occurred on the server while parsing the JSON text.
Invalid Request	-32600	The JSON sent is not a valid Request object.
Method Not Found	-32601	The method does not exist / is not available.
Invalid Param	-32602	Invalid method parameter(s).
Internal Error	-32603	Internal JSON-RPC error. Default error code for unexpected/uncaught errors.
Connect Errors	-32000 to -32099	Reserved for Connect defined errors. If an error is not explicitly defined below then it is reserved for future use and thus the EPoS should be capable of handling all codes in this range.
Connect Error	-32070	A Connect error has occurred on the server and further information is unavailable. Investigation may be needed.
Invalid Param Value	-32071	One or more of the received parameter values are invalid.
Request Not Processed	-32072	The received request has not been processed.
Response Not Processed	-32073	The received response has not been processed.
Request Timed Out	-32074	The Connect To EPoS request has timed out. Any response to this request will no longer be processed.
Unavailable Terminal	-32075	The request on a terminal was unable to be processed as the terminal is unavailable. The data provided with this error will contain a 'userMessage' key, which provides an informative message for the EPoS user to help troubleshoot this error. We recommend displaying this message when this error is encountered. PAC Integration Only: A Terminal Details request can provide confirmation of a terminal's availability or alternatively a Connected Terminals request can provide a full list of 'AVAILABLE' terminals.
Connection Discontinued	-32076	Notifies the EPoS that the websocket connection has been discontinued. This means any currently in progress transaction flows over this connection will continue to completion, however starting further transaction flows over this connection is forbidden.

Please note not all error messages are sent in reply to a request, so the 'id' element may be excluded.

A table of error message codes is below:

Message	Error Code	Description
Parse Error	-32700	Invalid JSON was received by the server. An error occurred on the server while parsing the JSON text.
Invalid Request	-32600	The JSON sent is not a valid Request object.
Method Not Found	-32601	The method does not exist / is not available.
Invalid Param	-32602	Invalid method parameter(s).
Internal Error	-32603	Internal JSON-RPC error. Default error code for unexpected/uncaught errors.
Connect Errors	-32000 to -32099	Reserved for Connect defined errors. If an error is not explicitly defined below then it is reserved for future use and thus the EPoS should be capable of handling all codes in this range.
Connect Error	-32070	A Connect error has occurred on the server and further information is unavailable. Investigation may be needed.
Invalid Param Value	-32071	One or more of the received parameter values are invalid.
Request Not Processed	-32072	The received request has not been processed.
Response Not Processed	-32073	The received response has not been processed.
Request Timed Out	-32074	The Connect To EPoS request has timed out. Any response to this request will no longer be processed.
Unavailable Terminal	-32075	The request on a terminal was unable to be processed as the terminal is unavailable. The data provided with this error will contain a 'userMessage' key, which provides an informative message for the EPoS user to help troubleshoot this error. We recommend displaying this message when this error is encountered. PAC Integration Only: A Terminal Details request can provide confirmation of a terminal's availability or alternatively a Connected Terminals request can provide a full list of 'AVAILABLE' terminals.
Connection Discontinued	-32076	Notifies the EPoS that the websocket connection has been discontinued. This means any currently in progress transaction flows over this connection will continue to completion, however starting further transaction flows over this connection is forbidden.

N/A

N/A

This is requested when the PDQ needs to display a list of currently open tables.

Should this request not be replied to within the timeout, it will be assumed that there are no open tables.

This is requested when the PDQ needs to display a list of currently open tables.

Should this request not be replied to within the timeout, it will be assumed that there are no open tables.

The 'tpi' value in this request is reserved for future use and for the time being will be set to its default value.

This list will be displayed on the terminal for the user to choose which table they would like to lock. On the user selecting a table the terminal will make a Table Lock Request before it attempts to complete the sale.

If there are no tables to lock, the tables value should be an empty array.

This list will be displayed on the terminal for the user to choose which table they would like to lock. On the user selecting a table the terminal will make a Table Lock Request before it attempts to complete the sale.

If there are no tables to lock, the tables value should be an empty array.

This request confirms to the terminal that it has the lock on a table, and that an EPoS user will be unable to change that table while the terminal is processing the transaction.

When the transaction has finished the terminal will send a Table Unlock Notification so the EPoS can unlock the table for use again, as well as a Transaction Response providing details of the transaction.

If the terminal's Waiter Id prompt is disabled, the 'WaiterId' value will be set to it's default value.

Should this request not be replied to within the timeout, it will be assumed that the table cannot be locked.

This request confirms to the terminal that it has the lock on a table, and that an EPoS user will be unable to change that table while the terminal is processing the transaction.

When the transaction has finished the terminal will send a Table Unlock Notification so the EPoS can unlock the table for use again, as well as a Transaction Response providing details of the transaction.

If the terminal's Waiter Id prompt is disabled, the 'WaiterId' value will be set to it's default value.

Should this request not be replied to within the timeout, it will be assumed that the table cannot be locked.

The 'tpi' value in this request is reserved for future use and for the time being will be set to its default value.

Once a terminal has confirmation of a table lock, it will prompt the user asking if they would like a receipt for the table, which if requested will invoke a POS Receipt Request.

Once a terminal has confirmation of a table lock, it will prompt the user asking if they would like a receipt for the table, which if requested will invoke a POS Receipt Request.

This is requested when a PDQ user wishes to print an EPoS receipt on the PDQ.

Should this request not be replied to within the timeout, a blank receipt will be sent to the terminal so the user can continue with the transaction.

This is requested when a PDQ user wishes to print an EPoS receipt on the PDQ.

Should this request not be replied to within the timeout, a blank receipt will be sent to the terminal so the user can continue with the transaction.

The 'tpi' value in this request is reserved for future use and for the time being will be set to its default value.

This is requested when a PDQ user wishes to print an EPoS receipt on the PDQ.

Should this request not be replied to within the timeout, a blank receipt will be sent to the terminal so the user can continue with the transaction.

The 'tpi' value in this request is reserved for future use and for the time being will be set to its default value.

The receipt is defined by an ordered array of receipt lines. Detailed information on how these can be defined can be found in the JSON schema above, but in summary each line can be an object of type:

Object Type	Description
Text	Standard text with optional formatting. Can be no longer than a defined length and is restricted to certain characters.
Graphic	A pre-defined graphic to visually separate groups of lines on the receipt. These include separators using printed lines or using white-space.
Image	An image defined by the EPoS sent encoded as a base 64 string. The image has size and file format restrictions dependent on the terminal type.
Barcode	Information printed on the receipt as a barcode. Only certain barcodes are supported dependent on the terminal type.

The receipt is defined by an ordered array of receipt lines. Detailed information on how these can be defined can be found in the JSON schema above, but in summary each line can be an object of type:

Object Type	Description
Text	Standard text with optional formatting. Can be no longer than a defined length and is restricted to certain characters.
Graphic	A pre-defined graphic to visually separate groups of lines on the receipt. These include separators using printed lines or using white-space.
Image	An image defined by the EPoS sent encoded as a base 64 string. The image has size and file format restrictions dependent on the terminal type.
Barcode	Information printed on the receipt as a barcode. Only certain barcodes are supported dependent on the terminal type.

This is requested if final-pos-receipt has been sent in the connection string. It is sent following the transactionResponse and prints a final receipt on the terminal following any payments.

Should this request not be replied to within the timeout, a blank receipt will be sent to the terminal so the user can continue with the transaction.

The response follows the same format as a standard posReceiptRequest. The receipt is defined by an ordered array of receipt lines. Detailed information on how these can be defined can be found in the JSON schema above, but in summary each line can be an object of type:

Object Type	Description
Text	Standard text with optional formatting. Can be no longer than a defined length and is restricted to certain characters.
Graphic	A pre-defined graphic to visually separate groups of lines on the receipt. These include separators using printed lines or using white-space.
Image	An image defined by the EPoS sent encoded as a base 64 string. The image has size and file format restrictions dependent on the terminal type.
Barcode	Information printed on the receipt as a barcode. Only certain barcodes are supported dependent on the terminal type.

If no transaction response is received, it can be assumed that no payments have taken place against the table.

To accommodate for the exceptional circumstance of a transaction response not being received for a table and there being no terminal currently processing a transaction for that table, we recommend the EPoS has the ability to manually record any payments taken for a table. This could be restricted to specific users or within a supervisor menu to prevent confusion with the normal transaction flow.

Please see the FAQs for details about when the amountCashback value will be set.

If no transaction response is received, it can be assumed that no payments have taken place against the table.

To accommodate for the exceptional circumstance of a transaction response not being received for a table and there being no terminal currently processing a transaction for that table, we recommend the EPoS has the ability to manually record any payments taken for a table. This could be restricted to specific users or within a supervisor menu to prevent confusion with the normal transaction flow.

Please see the FAQs for details about when the amountCashback value will be set.

If no transaction response is received, it can be assumed that no payments have taken place against the table.

To accommodate for the exceptional circumstance of a transaction response not being received for a table and there being no terminal currently processing a transaction for that table, we recommend the EPoS has the ability to manually record any payments taken for a table. This could be restricted to specific users or within a supervisor menu to prevent confusion with the normal transaction flow.

Please see the FAQs for details about when the amountCashback value will be set.

To accommodate for the edge case of an unlock notification not being received and there being no terminal currently processing a transaction (and hence holding the lock) for that table, we recommend the EPoS has the ability to manually unlock a table. This could be restricted to specific users or within a supervisor menu to prevent confusion with the normal transaction flow.

To accommodate for the edge case of an unlock notification not being received and there being no terminal currently processing a transaction (and hence holding the lock) for that table, we recommend the EPoS has the ability to manually unlock a table. This could be restricted to specific users or within a supervisor menu to prevent confusion with the normal transaction flow.

This is only available for 'END_OF_DAY' reports. This notification will not be sent for other report types.

This is only available for 'END_OF_DAY' reports. This notification will not be sent for other report types.