Go-live checklist
Dojo is committed to providing the best possible experience for our mutual customers. To achieve this, we require that all integrations meet our minimum requirements. As part of this process, our team will conduct UAT testing with you before accrediting your solution to be used with our customers.
To facilitate a smooth onboarding experience with our Pay-at-Table integration, Dojo has prepared a comprehensive testing checklist. Please use this checklist as a reference for self-accreditation before Dojo performs UAT.
If you're ready to begin UAT testing with us, or require development support, you can reach out to our team using the links at the bottom of this page.
Configuration
These tests relate to the configuration of the integration on your POS.
| Scenario | Steps to Reproduce | Expected Outcome |
|---|---|---|
| Incorrect authorization credentials. | Input an invalid API Key, then attempt to establish a connection with the EPOS Data API. | The POS should display an appropriate error message and / or status code indication authorization was unsuccessful. |
| API Version used. | Record the version of the API developed against, this should be hard-coded. | Version header is not able to be manipulated on the POS. |
| Minimum version of POS support. | Record the minimum version of the POS that supports the integration. | This must be shared with Dojo during the accreditation process |
| Implementation. | Record whether or not you are using our REST, Websocket or a mixture of both interfaces. | This will be recorded by Dojo during the accreditation process. |
Registering Capabilities
In the Dojo EPOS Data API, capabilities represent specific actions that the POS system can perform. These capabilities are linked to corresponding API endpoints in the POS system. By defining these capabilities, the POS system communicates to Dojo which features are supported and accessible.
| Scenario | Steps to Reproduce | Expected Outcome |
|---|---|---|
| Get all registered capabilities | The POS should have the ability to retrieve all currently registered capabilities | The registered capabilities do not need to be displayed to the user, but should be accessible if needed. This can be used to confirm that the correct capabilities are registered for Pay-At-Table. |
| Register a new capability. | All capabilities needed for the integration should be registered. | Capabilities should be based on what a specific customer can support, therefore the POS should be able to support all endpoints for every customer, or register specific capabilities based on requirement. |
Orders
These tests cover Orders. The Order entity represents the core component of the Ordering API, containing all relevant information about an order placed by customers at a given location. An order can consist of multiple items, each with details like status, quantity, price, and applied modifiers. If order locking capabilities are registered, the POS must be able to respond to payment flows initiated by both GetOrderById and CreateOrderLock requests.
| Scenario | Steps to reproduce | Expected outcome |
|---|---|---|
SearchOrders request with payableOnly set to true. | Using the Epos tester tool or the Dojo card machine, initiate a SearchOrders request. | The POS should only return tables that are available to be paid. |
| GetOrderById. | Using the Epos tester tool or the Dojo card machine, initiate a GetOrderById request by selecting an order to pay from the Order list. | The POS should return information about the specific order requested. |
| Water ID Validation. | Using a Dojo Card machine, initiate a SearchOrders request while entering a waiter ID. | Dojo will record whether or not the POS validates the waiterId field and only returns tables available to that waiter. |
Status is returned as required. | Using the Epos tester tool or the Dojo card machine, initiate a SearchOrders request. | Not all statuses are required to be supported, but a status must be returned in the response for SearchOrders. Dojo will record the statuses that are supported by the POS. |
ItemLines are supported. | Using the Epos tester tool or the Dojo card machine, initialize a search orders request. Initiate a GetOrderById by using the "Print Bill" function to print the POS bill. | ItemLines should be returned in the correct format. This is a pre-requisite to be able to print POS bills from the card machine. |
| Order Locking is implemented. | When registered as a capability, initiate a CreateOrderLock request by selecting an order using the Dojo Card Machine and pay off the bill; initiate a DeleteOrderLock by completing or exiting out of the payment flow. | If supported, the POS should lock the order when requested, preventing further manipulation to the order items or status, and unlock when requested. |
Record a Payment
These tests cover the RecordOrderPayment capability and the different variations of how a guest may choose to pay.
| Scenario | Steps to reproduce | Expected outcome |
|---|---|---|
| Successful payment in full. | Using a Dojo card machine, pay an order in full without splitting the bill. | The POS should record the payment, including its paymentIntentId, against the order. |
| Payment in full with split bill. | Using a Dojo card machine, pay an order in full by choosing either of the split options and splitting the bill by at least 2 payments. | The POS should record each payment, including its paymentIntentId, against the order. |
| Payment in full with split bill and Gratuity. | Using a Dojo card machine, pay an order in full by choosing either of the split options and splitting the bill by at least 2 payments; add gratuity to at least one of the payments. | The POS should record each payment, including its paymentIntentId and tipsAmount.value, against the order. |
| Partial Payment with and without gratuity. | Using a Dojo card machine, pay an order by choosing either of the split options and split by at least 2 ways; add gratuity to the first payment; after completing the first payment, exit out of the payment flow by selecting cancel. | The POS should record the payment, including its paymentIntentId and tipsAmount.value, against the order; the order should then return to a payable state and the outstanding balance should reflect the payment(s) taken. |
Refunds
These tests cover Refunds. Any payments taken via the Epos Data API can be refunded without the cardholder present through the Dojo API's Matched Refund function.
| Scenario | Steps to reproduce | Expected outcome |
|---|---|---|
| Successful Matched Refund. | Create a terminal session via the Dojo API with a session type of matched refund. | The POS should be able to initiate a Matched Refund and call the Payment Intent endpoint to confirm the refund was successful. |
| Unsuccessful Matched Refund. | The POS should store the paymentIntent ID against the orderId, so they can make use of integrated centralized refunds. | In case of the refund not being successful, the POS should display an appropriate error to the user. |
Error Handling
These tests cover some of the possible ways in which errors can occur and aim to create additional resilience.
| Scenario | Steps to reproduce | Expected outcome |
|---|---|---|
| Websocket disconnection handling. | If the API is hosted by Websocket, the POS should periodically check the connection status of the maintained Websocket to guard against network related incidents. | If the socket disconnects the connection should be re-established as soon as possible. |
| GetOrderById - none existent ID. | Using the Epos tester tool, Initiate a GetOrderById with an ID that does not exist. | The POS should return an appropriate error to the request. |
Support Our Partner Enablement team is always happy to help with any questions you have.
Stack Overflow Find answers to practical questions.