--- title: "Make Pay-at-table payments" description: "How to use terminal initiated payment flows like Pay at table or Pay at curbside." url: "https://docs.adyen.com/point-of-sale/pay-at-x" source_url: "https://docs.adyen.com/point-of-sale/pay-at-x.md" canonical: "https://docs.adyen.com/point-of-sale/pay-at-x" last_modified: "2020-11-02T12:21:00+01:00" language: "en" --- # Make Pay-at-table payments How to use terminal initiated payment flows like Pay at table or Pay at curbside. [View source](/point-of-sale/pay-at-x.md) To accept payments from your customers at a table, in a hotel room, or curbside, you can initiate payments from a terminal while keeping the terminal integrated with your POS system. The terminal initiated payment flow offers: * Equal and unequal split payments. * Support for all [payment methods](/point-of-sale/what-we-support/payment-methods) that you added to your account, as well as cash. * Easy combination with [tipping](/point-of-sale/tipping) options.\ Customers can enter a tip amount on the terminal with every split payment. If you let your staff authenticate when they start the payment from the terminal, you can then log the tip with that staff member to avoid adjusting tips later. For Pay at table you need to use [portable payment terminals](/point-of-sale/what-we-support/select-your-terminals#portable). These terminals have an integrated printer and a Wi-Fi connection, and can automatically switch to a cellular connection if the Wi-Fi connection drops. ## Requirements Before you begin, take into account the following requirements, limitations, and preparations. | Requirement | Description | | -------------------- | --------------------------------------------------------------------------------------------------------- | | **Integration type** | A [Terminal API](/point-of-sale/design-your-integration/terminal-api) integration with payment terminals. | | **Hardware** | The payment terminal must have an integrated printer and support both Wi-Fi and cellular connections. | | **Limitations** | Authentication by swiping the employee card is not supported on Android payment terminals. | ## How it works After you have [configured Pay at table](#enable-sale-wake-up), the flow is as follows: 1. On the terminal, your staff selects a button to [start Pay at table](#information-for-your-staff), and authenticates by entering their reference number or swiping their employee card. 2. The terminal sends a [SaleWakeUp event notification](#salewakeup-event-notification) to the POS system. The notification informs the POS system that the terminal is waiting to receive a payment request. 3. Based on the employee's authentication, you decide which bill to send a payment request for. If there are multiple bills, you send an `InputRequest` to the terminal so that your staff can provide more details. For example, ask for a table number, a choice from a list of bills, or a ride number. See [1. Retrieve the sale transaction](#collect-input). 4. You send a [`PrintRequest` ](/point-of-sale/shopper-engagement/print-data)to print the bill using the terminal. This is optional. It depends on your business needs whether to do this and when. 5. You send a [`PaymentRequest` ](#make-a-payment)from the POS system to the terminal. See [2. Make a payment](#make-a-payment). 6. The terminal shows the amount due, **Split check**, and options to: * Split the bill <**equally**. The terminal will ask for the number of splits. * Split the bill **unequally**. The terminal will ask for the amount of the first split. This is also the option to choose if a single customer is paying the whole bill. 7. Then the terminal shows the split amount and options to: * Pay by **card**. Your staff hands the terminal to the customer so that they can pay their split and, if configured, respond to the tipping options on the terminal. * Pay in **cash**. Your staff receives the cash and selects a button on the terminal display to confirm. If you do not want to accept cash payments, we can configure skipping the prompt for cash or card. 8. After the split payment is approved and sent, the terminal prints a receipt. 9. You process the split payment response, to keep track of the amount that has been paid. See [3. Process the payment result](#receive-result). 10. If there is a remaining amount due, you send the [next `PaymentRequest`](#next-payment-request) with the new `RequestedAmount` and `PaidAmount`.\ The terminal then shows options to: * **Pay later**. This is used for a group of customers who want to pay their share of the bill at different times. The terminal shows **Cancelled**. When someone else from the group is ready to pay, your staff needs to start Pay at table again. * **Pay remainder**. With equal splits, the terminal calculates the amount of the next split payment based on the number of splits. With unequal splits, the terminal shows the remaining amount and your staff enters the amount of the next split payment. This continues until the full amount has been paid. ## Configure Pay at table To enable Pay-at-table: 1. [Set up event notifications](/point-of-sale/design-your-integration/notifications/event-notifications). This is necessary to let the terminal send a **SaleWakeUp** event notification to the POS system. This notification informs the POS system that the terminal is waiting to receive a payment request. 2. Configure settings in your Customer Area: 1. In your [Customer Area](https://ca-test.adyen.com/), go to **In-person payments** > **Payment devices**, and select the **Terminals** tab. 2. Select your terminal from the list of terminals. 3. On the **Settings** page, go to **Integrations** > **Notification button**. 4. Turn on the **Enable notification button** toggle switch. 5. Show or hide the notification button. If the notification button is hidden, your staff can start a transaction by selecting the **Confirm** key **![](/images/1/9/d/b/6/19db69a93d641f6391db65a1563de3ade9ce55bb-confirm2x.png)** on the keypad. 6. Set the following values: | Field | Description | | --------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | Notification category | Select **Sale wake up**. | | Title | Enter the text to show on the button that starts the flow from the terminal. For example, *Pay\@tTable* | | Details | Enter the text to ask your staff to enter their reference number or swipe their employee card.The reference or card number can be a maximum of 10 digits.If you leave this field empty, the terminal sends the **SaleWakeUp** event notification immediately when the button is selected, and the notification does not include the reference or card number. | 7. Select **Save**. 3. Contact our [Support Team](https://ca-test.adyen.com/ca/ca/contactUs/support.shtml?form=other) to: * Set your staff's authentication method: Entering a reference number, or swiping an employee card. * If you do not want to accept cash payments, skip prompting for cash or card. 4. Add logic to your POS system so that it is able to handle the [`SaleWakeUp` event notification](#salewakeup-event-notification). ### SaleWakeUp event notification The [`SaleWakeUp` ](/point-of-sale/design-your-integration/notifications/event-notifications#sale-wake-up)event notifications that the terminal sends to the POS system include: * `EventToNotify`: **SaleWakeUp** * `EventDetails`: The employee's reference number or employee card number. For example, **reference\_id=0123456789**. You can use this to retrieve the associated bill, or to log sales and tips by staff member. **Example SaleWakeUp notification** ```json { "SaleToPOIRequest":{ "EventNotification":{ "EventDetails":"reference_id=0123456789", "EventToNotify":"SaleWakeUp", "TimeStamp":"2019-11-15T10:16:10.000Z" }, "MessageHeader":{ "DeviceID":"1517998561", "MessageCategory":"Event", "MessageClass":"Event", "MessageType":"Notification", "POIID":"V400m-324688179", "ProtocolVersion":"3.0", "SaleID":"POSSystemID12345" } } } ``` ## 1. Retrieve the sale transaction When the POS system receives a `SaleWakeUp` event notification: 1. Get the reference or employee card number received in the `EventDetails` field of the event notification. 2. Retrieve the sale transactions (the bills) associated with the reference number or employee card number, or with the terminal. 3. If there is only one open bill, skip to [2. Make a payment](#make-a-payment). 4. If there are more open bills, [make an input request](/point-of-sale/shopper-engagement/shopper-input) (or a series of input requests) to ask your staff to enter more information on the terminal.\ For example, first ask for the table number with a [text input request](/point-of-sale/shopper-engagement/shopper-input/text). Then send a [menu input request](/point-of-sale/shopper-engagement/shopper-input/menu) to show a list of bills associated with the table number and ask your staff to select one. While an input request is being processed, you can optionally show a waiting screen animation. You can do this by [creating a session](/point-of-sale/shopper-engagement/create-session) that spans multiple input requests. 5. Process the responses to your input requests so that your POS system is able to retrieve the correct bill to send a payment request for. ## 2. Make a payment Technically Pay-at-table is a split payments flow. You make several subsequent payment requests for the same sale until the full amount has been paid. If a single customer pays the entire bill, that is an unequal split for the full amount, and you need to make only one split payment request. In this split payments flow, you: * Set the split payments flag to **true** in each payment request. * Specify a unique sale transaction ID in the first payment request, and repeat that same ID in all subsequent split payments for the same sale. * Make sure that your POS system keeps track of the amount that has been paid already. After you have received a `SaleWakeUp` event notification from the terminal and collected information to determine for which bill the terminal wants to receive a payment request, proceed as follows: 1. Optional. From your POS system, send a `PrintRequest` to let the terminal print the bill. 2. [Make a payment request](/point-of-sale/basic-tapi-integration/make-a-payment), including: * The [PaymentRequest](https://docs.adyen.com/api-explorer/terminal-api/latest/post/payment) object with: | Parameter | Required | Description | | ------------------------------- | ------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | `SaleData.SaleTransactionID` | ![-white\_check\_mark-](/user/data/smileys/emoji/white_check_mark.png "-white_check_mark-") | An object with `TransactionID` containing your reference for the sale (for example, the bill for table 5), and `TimeStamp` containing the date and time of the request in [UTC format](https://en.wikipedia.org/wiki/ISO_8601#Coordinated_Universal_Time_\(UTC\)).All split payments belonging to the same sale (the same bill) must use this same `TransactionID`. | | `PaymentTransaction.AmountsReq` | ![-white\_check\_mark-](/user/data/smileys/emoji/white_check_mark.png "-white_check_mark-") | An object that indicates how much remains to be paid and how much has been paid already:- `Currency`: The [currency](/development-resources/currency-codes) of the transaction. - `RequestedAmount`: The amount that remains to be paid. For the first split payment, this is the full sale amount. For a subsequent split payment, this is the sale amount minus the `PaidAmount`. - `PaidAmount`: The amount that has already been paid. For the first split payment, this is zero. For a subsequent split payment, this is the sum of the amounts paid in previous split payments for the same sale. | | `PaymentData` | ![-white\_check\_mark-](/user/data/smileys/emoji/white_check_mark.png "-white_check_mark-") | An object that sets the split payment flag, with:- `PaymentType`: **Normal** - `SplitPaymentFlag`: **true** | You can add other `PaymentRequest` fields as needed. For example to trigger the terminal to show the [tipping](/point-of-sale/tipping) options you configured. **First Pay at table payment request** ```json { "SaleToPOIRequest": { "MessageHeader": { "ProtocolVersion":"3.0", "MessageClass":"Service", "MessageCategory":"Payment", "MessageType":"Request", "SaleID":"POSSystemID12345", "ServiceID":"0207111104", "POIID":"V400cPlus-301506502" }, "PaymentRequest": { "SaleData": { "SaleTransactionID": { "TransactionID": "9820s", "TimeStamp": "2019-11-12T12:58:23.000Z" } }, "PaymentTransaction": { "AmountsReq": { "Currency": "USD", "RequestedAmount": 89.65, "PaidAmount": 0 } }, "PaymentData": { "PaymentType": "Normal", "SplitPaymentFlag": true } } } } ``` The payment request is routed to the terminal. This shows options to split **Equally** or **Unequally**, as described in [How it works](#pay-at-x-flow).\ When the payment is processed, you [receive the payment result](#receive-result). 3. If only a partial amount has been paid, send the next split payment request with a new `RequestedAmount` and `PaidAmount` as shown in the following example.[]() The terminal will show options to **Pay later** or **Pay remainder**. If **Pay remainder** is selected, the terminal automatically calculates the next split in case of equal splits, or asks for the next amount in case of unequal splits. **Request for the next split payment after USD 20 has been paid** ```json { "SaleToPOIRequest": { "MessageHeader": {...}, "PaymentRequest": { "SaleData": { "SaleTransactionID": { "TransactionID": "9820s", "TimeStamp": "2019-11-12T13:44:20.000Z" } }, "PaymentTransaction": { "AmountsReq": { "Currency": "USD", "RequestedAmount": 69.65, "PaidAmount": 20 } }, "PaymentData": { "PaymentType": "Normal", "SplitPaymentFlag": true } } } } ``` ## 3. Process the payment result When you receive the payment response for a split payment: 1. Determine whether more split payments are needed to pay off the bill. In the [PaymentResponse](https://docs.adyen.com/api-explorer/terminal-api/latest/post/payment#responses-200): * `Response.Result`: **Success** indicates the full `RequestedAmount` has been paid. **Partial** indicates there is still an amount due, so more split payments are needed. 2. If more split payments are needed, keep track of the amount that has been paid. In each next split payment request for the same sale, you need to specify the total amount paid through the previous split payment(s) in the `PaidAmount` field, and adjust the `RequestedAmount` with the remaining amount due. To keep track, check these response fields: * `SaleData.TransactionID`: Includes the `TransactionID` of the sale (the bill) that the split payment belongs to. * `AmountsResp.AuthorizedAmount`: The amount that has been paid with this transaction. **Response for a partial card payment of USD 20** ```json { "SaleToPOIResponse": { "MessageHeader": {...}, "PaymentResponse": { "POIData": {...}, "SaleData": { "SaleTransactionID": { "TimeStamp": "2019-11-12T12:58:23.000Z", "TransactionID": "9820s" } }, "PaymentResult": { "OnlineFlag": true, "PaymentAcquirerData": {...}, "PaymentInstrumentData": { "CardData": {...} }, "PaymentInstrumentType": "Card" }, "AmountsResp": { "AuthorizedAmount": 20, "Currency": "USD" }, "PaymentType": "Normal" }, "Response": { "Result": "Partial", "AdditionalResponse": "tid=01506502&AID=A0000000041010&transactionType=GOODS_SERVICES&backendGiftcardIndicator=false&posadditionalamounts.originalAmountValue=2000&..." } } } } ``` **Sample response for cash payment of the full remaining amount** ```json { "SaleToPOIResponse": { "MessageHeader": {...}, "PaymentResponse": { "POIData": {...}, "SaleData": { "SaleTransactionID": { "TimeStamp": "2019-11-12T13:44:20.000Z", "TransactionID": "9820s" } }, "PaymentResult": { "OnlineFlag": false, "PaymentAcquirerData": {...}, "PaymentInstrumentData": { "PaymentInstrumentType": "Cash" }, "AmountsResp": { "AuthorizedAmount": 69.65, "Currency": "USD" }, "PaymentType": "Normal" }, "Response": { "Result": "Success" } } } } ``` * In the [PaymentResponse](https://docs.adyen.com/api-explorer/terminal-api/latest/post/payment#responses-200), also note the following: * `PaymentResult.OnlineFlag`: **true** for a card or wallet payment, or **false** for a cash payment. * `PaymentResult.PaymentInstrumentData.PaymentInstrumentType`: **Cash** or **Card** * `Response.AdditionalResponse`: Additional transaction data. Depending on the format you used in the request, you receive either a string of form-encoded key-value pairs or a Base64 string that you need to decode to get a JSON object. For a cash payment, this field is not included. * If **Pay later** is selected on the payment terminal when it receives a request for a subsequent split payment, the terminal shows **Cancelled**. You receive a payment result containing: * `PaymentResponse.Response.Result`: **Failure** * `PaymentResponse.Response.ErrorCondition`: **PaymentRestriction**. This indicates that the Pay-at-table flow was interrupted. It is not the preceding split payment that failed. * If the payment failed, the terminal shows **Declined** and you receive a payment result containing: * `PaymentResponse.Response.Result`: **Failure** * `PaymentResponse.Response.ErrorCondition`: Indicates why the payment failed. For example, **Refused** indicates the card issuer refused the transaction, and **Cancel** indicates the transaction was cancelled on the terminal. Refer to our [refusal reasons documentation](/point-of-sale/error-scenarios/refusal-reasons-pos). ## Information for your staff #### Authentication To start Pay at table, your staff selects the button you [configured](#enable-sale-wake-up). Then they need to authenticate. On the terminal, they can: * Enter their employee reference number. * Swipe their employee card. This authentication method is only available on non-Android terminals. If employees usually authenticate by swiping their employee card but do not have their card available, they can select the **Cancel** key **![](/images/e/b/5/8/6/eb5864c171bd3eac47d4a415a1f7e5dc0b075c28-cancel2x.png)** to switch to entering their reference number. To switch back to swiping, they need to select the **Cancel** key again. #### Previous step or cancel After starting Pay at table, your staff can: * Press **![](/images/6/a/c/0/f/6ac0f714f7f71ab24441a67d694875057c0ad00c-correct2x.png)** to go back a step in the flow. This is possible until the moment **Cash** or **Card** is selected. * Press **![](/images/e/b/5/8/6/eb5864c171bd3eac47d4a415a1f7e5dc0b075c28-cancel2x.png)** to cancel the flow at any point. #### Keeping your staff informed The terminal will show the usual progress messages while a payment is processed. However, any errors occurring at other moments in the Pay-at-table flow are received at the POS system. Because your staff is not near the POS system, they do not know what happened and what they need to do. To help them, you can [make a display request](/point-of-sale/shopper-engagement/display-data/display-receipt/) to send a message from the POS system to the terminal. ## See also * [Accept tips with your Pay-at-table payments](/point-of-sale/tipping) * [Use the terminal to get input for the payment request from your staff](/point-of-sale/shopper-engagement/shopper-input) * [Send a message from the POS system to the terminal, to keep your staff informed](/point-of-sale/shopper-engagement/display-data/display-receipt) * [Set up event notifications and view sample notifications](/point-of-sale/design-your-integration/notifications/event-notifications)