Test cases

The Tables API is now archived. For up-to-date Pay at Table integrations, please use the Dojo API and EPOS Data API:

These test cases In order to allow your POS integration to be used in production, it is required that your POS successfully passes each of the scenarios listed below.

info

To fully test each scenario, you will need to review Simulating messages

Payment app test cases

When you wish to test scenarios that are being sent to and from a card machine, all requests to the EPOS will contain the following requestorInfo in the request body:

{ 
    "requestorInfo": {
        "requestorType": "REQUESTOR_TYPE_CARD_MACHINE",
        "cardMachineRequestorInfo": {
            "terminalId": "XXXXXXXX"
        }
    }
}

If the waiterId is also required, it can be sent in the request to the EPOS at requestorInfo.cardMachineRequestorInfo.waiterId.

Waiter ID

For any endpoint that needs to check if a particular session exists (GetBillItems, GetFullBill, GetSession, LockSession, UnlockSession, RecordPayment), you may choose to implement additional logic to filter the data using the waiter ID. In this scenario, you will need to enforce the following logic across each of the listed endpoints. Similarly, you may wish to optionally add the following logic to the List variations of these endpoints or alternatively return empty sets instead of errors.

Test case	Expected behaviour
Session lookup - with no waiter ID specified	Conditional if POS logic on the waiter ID is not required. Continue with the specific request's logic. Conditional if POS logic on the waiter ID is required. The POS should return an Error Response with an error code of `WAITER_INCORRECT_WAITER_ID` and a message explaining that no waiter ID is specified.
Session lookup - with existing and correct waiter ID	Optional if POS logic on the waiter ID is required. When the waiter ID is specified in the request to the POS (if waiter ID is turned on on the card machine) and the session's waiter ID matches, then continue with the specific request's logic.
Session lookup - with existing but incorrect waiter ID	Optional if POS logic on the waiter ID is required. The session attempted to be retrieved is owned by a waiter that exists in the POS but one that isn't assigned to this session. The POS should return an Error Response with an error code of `WAITER_INCORRECT_WAITER_ID` and a message explaining that it's the wrong waiter.
Session lookup - with non-existing waiter ID	Optional if POS logic on the waiter ID is required. The session attempted to be retrieved is owned by a waiter that does not exist in the POS. The POS should return an Error Response with an error code of `WAITER_INCORRECT_WAITER_ID` and a message explaining that the waiter does not exist.

Consumer device test cases

When you wish to test scenarios that are being sent to and from a consumer device, all requests to the EPOS will contain the following requestorInfo in the request body:

{ 
    "requestorInfo": {
        "requestorType": "REQUESTOR_TYPE_CONSUMER_DEVICE",
        "consumerDeviceRequestorInfo": { }
    }
}

All test scenarios

When going through the following test cases, it is important to bare in mind that both requests from a card machine and a consumer device must be supported. If the EPOS does not require any logic to be built around the waiterId, the logic should be exactly the same in both scenarios. Otherwise, the logic for requests to and from a card machine will be more restrictive. As a result, be sure to validate all the test scenarios return the expected results for both request types.

GetBillItems

Test case	Expected behaviour
Get Bill Items - With non-existent session ID	The POS should return an Error Response with an error code of `SESSION_NO_SUCH_SESSION`
Get Bill Items - With no items	Assuming that the POS allows a session to exists before any items are added to it, requesting the bill items should result in an empty array of `billItems.items`
Get Bill Items - With some items	Given that a session is created and some items are added to the bill, requesting the bill items should return the same items entered on the POS
Get Bill Items - With some duplicate items	Given that a session is created and some duplicate items are added to the bill, requesting the bill items should return the same items entered on the POS in the correct quantities.
Get Bill Items - With some modified items	Conditional if `billItems.items[].modifiers` are supported. Given that a session is created and some modified items are added to the bill, requesting the bill items should return the same items entered on the POS.
Get Bill Items - With some duplicate and modified items	Conditional if `billItems.items[].modifiers` are supported. Given that a session is created and duplicate modified items are added to the bill, requesting the bill items should return the same items entered on the POS in the correct quantities
Get Bill Items - With partial payment	Given that a session is created and some items are added to the bill, once a partial payment is made, requesting the bill items should return the same items entered on the POS in the correct quantities and should reflect the partial payment
Get Bill Items - With full payment	Given that a session is created and some items are added to the bill, once a full payment is made, requesting the bill items should return the same items entered on the POS in the correct quantities and should reflect the full payment

GetFullBill

Test case	Expected behaviour
Get Full Bill - With some items	You should be able to add some items to a session on a table, select the session from your card machine and print the bill. The bill should show all the items you entered on the POS correctly along with the correct quantities and bill amount

GetSession

Test case	Expected behaviour
Get Session - With existing session ID	The POS should return the session
Get Session - With non-existing session ID	The POS should return an Error Response with an error code of `SESSION_NO_SUCH_SESSION`
Get Session - For multiple sessions with a unique ID for both	The POS should return two separate sessions with unique session IDs
Get Session - With a unique session ID after session completion	Validate that after all payments are made on a session that upon retrieving the session, the session ID is the same value as it was on creation
Get Session - With a valid createdAt timestamp at session creation	Validate that after creating a session, an accurate `createdAt` timestamp is set
Get Session - With a valid createdAt timestamp at session completion	Validate that after all payments are made on a session that upon retrieving the session, the `createdAt` timestamp is the same value as it was on creation
Get Session - With a valid finishedAt implementation at session creation	Validate that after creating a session, no `finishedAt` timestamp is set
Get Session - With a valid finishedAt implementation at session completion	Validate that after all payments are made on a session that upon retrieving the session, the `finishedAt` timestamp is set accurately
Get Session - With a valid isPayable implementation at session creation	Validate that after creating a session, with bill items assigned to the session that the session assigns `isPayable=true`
Get Session - With a valid isPayable implementation at session completion	Validate that after all payments are made on a session that upon retrieving the session, `isPayable=false` is assigned
Get Session - With a valid table name at session and table creation	Validate that after ordering some items on the POS at a table that a session is created with the corresponding `tableName`
Get Session - With a valid table name at session and table completion	Validate that after all payments are made on a session at a table that upon retrieving the session, the `tableName` matches the one it was created with
Get Session - Without setting number of covers	The POS should not allow a table with zero covers or default to at least 1 cover. The Tables API will reject any session where the covers are below 1
Get Session - After setting number of covers	Validate that after placing a hold on a table on the POS, the `numberOfcovers` matches that which was entered on the POS
Get Session - Before and after transferring from one table to another	Validate that after placing a hold on a table on the POS, the `tableName` matches what was selected upon POS. Transfer the party to another table on the POS and ensure the session now reflects the new `tableName`

GetTable

Test case	Expected behaviour
Get Table - With an existing table name	The POS should return the table
Get Table - With a non-existing table name	The POS should return an Error Response with an error code of `TABLE_NO_SUCH_TABLE`
Get Table - With covers	Assuming that the POS has defaults for the maximum covers each table can take, the POS should return the table with the maximum covers for the table
Get Table - With no covers	The POS should actively prevent the waiter from reducing the number of covers to zero
Get Table - With an active session	Assuming that a session takes place on a given table, the POS should allow retriving this table
Get Table - With no active session	Assuming that no session takes place on a given table, the POS should return the table
Get Table - When table status is available	Using a table where the table status is `TABLE_STATUS_AVAILABLE`, the POS should allow retrieving this table
Get Table - When table status is occupied	Using a table where the table status is `TABLE_STATUS_OCCUPIED`, the POS should allow retrieving this table
Get Table - When table status isn't in pending available [optional]	Optional if the POS supports `TABLE_STATUS_PENDING_AVAILABLE`. Using a table where the table status is pending available, the POS should allow retrieving this table
Get Table - When table status isn't in use [optional]	Optional if the POS supports `TABLE_STATUS_NOT_IN_USE` Using a table where the table status is pending available, the POS should allow retrieving this table

ListBillItems

Test case	Expected behaviour
List Bill Items - With no params	The POS should return all bill items for all sessions (The POS can restrict this to only payable sessions to prevent running an expensive query).
List Bill Items - With one valid session ID in params	The POS should only return the bill items for specified session
List Bill Items - With one valid session ID and one non-existing session ID	The POS should only return the bill items for specified session. No errors should be returned for the session that does not exist
List Bill Items - With two valid session IDs	The POS should return the bill items for both specified sessions

ListSessions

Test case	Expected behaviour
List Sessions - With no params	The POS should returned all sessions

Testing the params

There are four different parameters that filter the results of List Sessions:

hasTable: hasTable=true should return only sessions that have a valid name in Session.tableName, whereas hasTable=false should return session where Session.tableName isn't defined
isFinished: isFinished=true should return only sessions that have a timestamp in Session.finshedAt, whereas isFinished=false should return session where Session.finshedAt isn't defined
isPayable: isPayable=true should return only sessions where Session.isPayable=true, whereas isPayable=false should return session where Session.isPayable=false isn't defined
tableNames: Should return only sessions where Session.tableName matches one of the items in tableNames. When tableNames is blank, it should be ignored

As each parameter can be used in combination, each additional parameter should make the request more restrictive for example, hasTable=true and isFinshed=false should return all sessions that both have tables and are not finished.

ListTables

Test case	Expected behaviour
List Tables - With no params	The POS should returned all tables

Testing the params

There are four different tables statuses that filter the results of List Tables:

TABLE_STATUS_NOT_IN_USE: For tables that are marked out of use for example, Tables outside that are closed during the winter
TABLE_STATUS_PENDING_AVAILABLE: For tables that are vacant but may require cleaning by the waiting staff
TABLE_STATUS_AVAILABLE: For tables that are ready to accept a new party
TABLE_STATUS_OCCUPIED: For tables that are currently occupied by a seated party

As each status can be used in combination, each additional status should make the request less restrictive for example, hasTable=true and isFinshed=false should return all sessions that both have tables and are not finished.

LockSession

Test case	Expected behaviour
Lock Session - With non-existing session ID	The POS should return an Error Response with an error code of `SESSION_NO_SUCH_SESSION`
Lock Session - With an already locked session	The POS should return an Error Response with an error code of `SESSION_ALREADY_LOCKED`
Lock Session - With existing and unlocked session	The POS should lock the Session successfully

RecordPayment

Test case	Expected behaviour
Record Payment - With an unlocked session	The POS should return an Error Response with an error code of `SESSION_NOT_LOCKED`
Record Payment - When already recorded on the POS	The POS should be able to pick up duplicate payments where the same payment `id` is received with the same amount. The POS should return an Error Response with an error code of `PAYMENT_ALREADY_RECORDED`
Record Payment - With an non-existent session	The POS should return an Error Response with an error code of `SESSION_NO_SUCH_SESSION`
Record Payment - With a full payment for some items	You should be able to add some items to a session on a table, select the session from your card machine and make a full payment. This should result in creating a record of payment on the POS as well as freeing up the table
Record Payment - With a full payment for some items and gratuity	You should be able to add some items to a session on a table, select the session from your card machine and make a full payment with gratuity. This should result in creating a record of payment with gratuity on the POS as well as freeing up the table
Record Payment - With a split payment for multiple payees	You should be able to add some items to a session on a table, select the session from your card machine and make a split payment for the full amount. This should result in creating a record of payment for each individual payment on the POS as well as freeing up the table
Record Payment - Manually record a partial payment	You should be able to manually record a partial payment on the POS for a session. The outstanding amount displayed when attempting to complete the payment on the card machine should reflect the partial payment
Record Payment - With partial payment	You should be able to add some items to a session on a table, select the session from your card machine and make a partial payment. This should result in creating a record of payment on the POS for the partial payment without freeing up the table
Record Payment - With a cancelled payment	The POS should appropriately handle payments where `paymen.paymentSuccessful=false` and `cardPresentPaymentStatus=CARD_PRESENT_PAYMENT_STATUS_CANCELLED`. At the very least, the cancelled payment should be ignored at not affect the bill.
Record Payment - With a declined payment	The POS should appropriately handle payments where `paymen.paymentSuccessful=false` and `cardPresentPaymentStatus=CARD_PRESENT_PAYMENT_STATUS_DECLINED`. At the very least, the declined payment should be ignored and not affect the bill
Record Payment - With a unknown payment	The POS should appropriately handle payments where `paymen.paymentSuccessful=false` and `cardPresentPaymentStatus=CARD_PRESENT_PAYMENT_STATUS_UNKNOWN`. At the very least, the unknown payment should be ignored and not affect the bill

UnlockSession

Test case	Expected behaviour
Unlock Session - Force unlock from POS	The POS should allow a session that has been locked by the card machine to have a fall-back force unlock option.
Unlock Session - With non-existing session ID	The POS should return an Error Response with an error code of `SESSION_NO_SUCH_SESSION`
Unlock Session - With an unlocked session	The POS should return an Error Response with an error code of `SESSION_NOT_LOCKED`
Unlock Session - With existing and locked session	The POS should unlock the Session successfully

Payment app test cases​

Waiter ID​

Consumer device test cases​

All test scenarios​

GetBillItems​

GetFullBill​

GetSession​

GetTable​

ListBillItems​

ListSessions​

Testing the params​

ListTables​

Testing the params​

LockSession​

RecordPayment​

UnlockSession​

Payment app test cases

Waiter ID

Consumer device test cases

All test scenarios

GetBillItems

GetFullBill

GetSession

GetTable

ListBillItems

ListSessions

Testing the params

ListTables

Testing the params

LockSession

RecordPayment

UnlockSession