Pay At Table Addons¶
The pay at table feature allows customers to view the bill for a specified table, and to make a payment against it.
LOKE uses table bill to refer to the items/amount requiring payment on a table. Other systems may refer to this as an order, cheque/check, account, invoice etc.
To provide an addon that works with this feature the third-party system must meet the following requirements:
- Provide distinct/unique numeric table numbers to identify tables at a given location/store.
- Must be able to fetch a single active table bill on demand, given a numeric table number. Multiple table bills per-table are not supported.
- Must be able to assign multiple externally processed (by LOKE) payments against a table bill.
- Must allow for a table bill to be closed off when fully paid.
What Needs to be Built?¶
As an addon provide you will need to build the following components/functions:
- OAuth 2 authorization flow (authorization code based) to authenticate against LOKE's API.
- Implement a refresh token strategy to ensure your addon maintains a usable access token for LOKE's APIs.
- Provide a URL that allows LOKE to do a "fetch table bill by table number" for a location.
- Provide a URL that allows LOKE to do a "add payment to table bill" for a location.
- Provide a UI to perform location/store mapping (link locations in LOKE's services to locations in the third party addon).
- When a location is linked:
- Publish a list of available tables when a location is linked.
- Define a URL allowing LOKE to do a "fetch table bill by table number" for a location when a location is linked.
- Define a URL allowing LOKE to do a "add payment to table bill" for a location when a location is linked.
What if I already have an API?¶
If the third party system already has an API that must be used for this, then an additional system must be built as the addon to bridge the 2 APIs.
This bridging service/addon will likely need to authenticate against the third party API in addition to LOKE's API.
This is the same for any addon, not just pay at table:
Basic / Simple User Flow¶
Multiple Participants (Split Bills) Flow¶
There are multiple slow running asynchronous components in this solution, so there are some race conditions to consider. The following diagram indicates how LOKE will handle each condition, and how LOKE expects the third party to behave in each condition.