| Previous Topic |
|---|
| POS Module 10: Handling POS Disconnections - Concepts |
POS API Certification Tutorial - Module 10: Handling POS Disconnections - Example Scenarios
Prerequisites
-
You must have read the scenario assumptions.
General Tasks for Handling POS Queuing Transactions
Here is the general workflow for offline queuing transactions:
1. Spool the check API calls details (Receipt Details) in the event of network connectivity outage or server errors.
2. Cache check details locally. The POS will store POS check details and the assigned unique barcode locally on the POS for each transaction before sending them to the Punchh POS datasink.
3. Hold check details during network connectivity outages. During a network outage, hold the POS check details until network connectivity is restored for a minimum of 10 days and a maximum of 30 days.
4. Send check details using the Receipt Details API call after connectivity restoration. The POS will continue to attempt to re-send the POS check details until they are successfully received by the Punchh datasink or until the end of the maximum caching period. Sending of check details should occur in first-in, first-out (FIFO) order.
Possible Scenario
The following scenario is based on the assumptions here.
Story Line
As Rachel is starting her shift, she realizes that there is a network outage at Central Punchh Coffee. However, she will not let this affect the business or the customers. She knows that when there is any network or connectivity issue, the POS can queue and store transactions until network connectivity is restored for at least 10 days. So, she proceeds to take orders as usual. Note that when the POS connectivity to Punchh is lost, the POS scanner is not working, or the user does not want to check in at the POS, the POS prints a unique barcode on every POS transaction receipt. In this scenario, the POS has lost connection to the POS server so guests receive receipts with a barcode or QR code printed on them. It is important to note that the guest is responsible for scanning the barcode on the receipt with the mobile app to earn points. The guest earns loyalty points when the connectivity is restored and Punchh receives the transactions from the POS. Loyalty points will not accrue to the guest’s account until the network connectivity with the Punchh server is restored at the POS.
The POS continues to attempt to re-send the POS check details until they are successfully received by the Punchh datasink or until the end of the maximum caching period. Two days later, the network issues are fixed, and all of the orders that Rachel has taken in the past two days will be uploaded from local storage to the Punchh datasink in first-in, first-out (FIFO) order.
Code Sample (Direct API Integration)
There is no code sample for this scenario because the POS handles the network outage or server errors at the store level by queueing and storing transactions. The POS cannot contact the Punchh API server until the connection with the Punchh API server is restored.