Requestor
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.
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
.