Skip to main content

Requestor

Pay at Table integrations are currently standalone from Pay at Counter and Online payments. This is because the current version of the Tables API uses an asynchronous WebSocket protocol for its messaging.

Tables API integrations offer merchants various options for accepting payments, catering to both the traditional scenario of card machine payment, and other, consumer-driven use cases, like mobile QR code payments. In this context, the 'requestor' refers to the device or service initiating the payment.

Requestor info​

As a result, every request made to the POS will contain an requestorInfo object, which will be structured in one of the following formats:

Card machine​

{
    "requestorType": "REQUESTOR_TYPE_CARD_MACHINE",
    "cardMachineRequestorInfo": {
        "terminalId": "123456789",
        "waiterId": "001"
    }
}

Consumer device​

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

Custom logic​

For in-person card payments, some POS systems have custom logic based on the waiterId and the terminalId. For instance, there are terminals that are exclusively assigned to specific tables, and certain waiters may be assigned to particular areas of a restaurant.

It is crucial to note that this logic is applicable only when the requestorInfo.requestorType is set to REQUESTOR_TYPE_CARD_MACHINE. In the case of REQUESTOR_TYPE_CONSUMER_DEVICE, where the consumer is making a payment through their own device, the concepts of waiterId and tid do not apply.

tip

Make sure you consider the requestorInfo.requestorType when building any POS logic. The waiterId and terminalId will only be available when the requestor type is REQUESTOR_TYPE_CARD_MACHINE.

Last updated on