# Posting cancelled transactions

Posting a cancelled transaction result for a table.

**Sample URL schematics:**

* LAN-based Pay@Table: `http://[pos server IP address][:port]/open-sales`
* Cloud-based Pay@Table: `https://my.pos.server/open-sales`


The terminal sends an HTTP POST request to this URL, but only if the `always-return-outcome` flag
was set to `true` in the initial open sales request.

The message body contains the cancelled transaction result in JSON format (content type
`text/plain`), with the following data:

| Parameter | Description | Mandatory |
|  --- | --- | --- |
| `result` | Always `CANCELLED`. | Yes |
| `mid` | The Tyro Merchant ID. | Yes |
| `tid` | The Tyro Terminal ID. | Yes |
| `operator-id` | The operator ID used to process the transaction. | Yes |
| `table` | The table number. | Yes |


**Example:**


```json
{"mid":"123","table":"10","operator-id":"2175","result":"CANCELLED","tid":"111"}
```

**Error codes:**

* To acknowledge the request from the terminal, the POS server returns an HTTP status code of
200 (OK).
* Any other HTTP status code from the POS server is interpreted as a permanent error condition, and
the terminal resets ready for the next transaction. If the terminal receives no response from the
POS server, it continues to send the transaction result until a response is received.


Because the terminal resends transaction results until a response is received, POS servers should
handle duplicate receipt of transaction results. To let the POS server determine the authenticity
of the message, the terminal includes a Message Authentication Code (MAC) as an HTTP header named
`x-tyro-mac`. See
[Generating and verifying Message Authentication Codes](/docs/in-person-payments/pay-in-person/features/pay-at-table/testing#generating-and-verifying-message-authentication-codes)
for how to generate and verify the MAC for the message.

## Testing and troubleshooting connectivity between terminal and POS server

**Sample URL schematics:**

* LAN-based Pay@Table: `http://[pos server IP address][:port]/diagnostic`
* Cloud-based Pay@Table: `https://my.pos.server/diagnostic`


For testing and troubleshooting, the terminal makes an HTTP GET request to this URL. This checks
connectivity between the terminal and the POS server, and is available on the terminal via
**Menu > Settings > Network > Test POS server**.

To acknowledge the request, the POS server returns an HTTP status code of 200 (OK). The terminal
displays the HTTP status code on screen to help with troubleshooting.

This function can also confirm the passphrase is configured correctly: return some text content
along with the correct `x-tyro-mac` header, for example:

* Message: `Lorem ipsum dolor sit amet, consectetur adipiscing elit`
* Passphrase (secret): `p@ssphr@se`
* Transmitted MAC: `a236a563bb769f20883dd320389e72dd8b4f0571`


On receiving the request, the terminal computes the MAC from the received message and the
passphrase, then compares it with the received MAC. If they match, the passphrase is configured
correctly and the message text wasn't altered in transit between the POS Pay@Table server and the
terminal.

## Typical scenarios

The diagrams below show how the typical scenarios are handled.

**Scenario 1:** Restaurant mode — paying the full amount.

![Restaurant mode: paying the full amount](/assets/paytable-scenario-full-payment.fe3f52aabc99088f0cb47e23e01dc15fcbb7e44e9a027dcc8d651d6202875c8f.68286485.png)

**Scenario 2:** Restaurant mode — splitting the bill.

![Restaurant mode: splitting the bill](/assets/paytable-scenario-split-bill.3b8dfc7539faf32d291f7557e6a7269a048bb63ee1e309862ba7ab9662f0a762.68286485.png)

**Scenario 3:** Retail mode.

![Retail mode](/assets/paytable-scenario-retail.0d9160aecf8c2fcc3c010595089618d96326a23a4174f972e6ec05b84637028c.68286485.png)

Continue to [Testing](/docs/in-person-payments/pay-in-person/features/pay-at-table/testing).