Can guests order and pay from a table tag?
Yes, and two things decide whether it survives contact with a dining room. The tag has to say which table this is, and the service behind it has to assume the tag can be replaced, because a swapped tag sends a whole room somewhere else and nothing written on a tag can prevent that.
The table identifier
An order needs to arrive attached to a table, so each table carries its own address. That is a write per table and a record per table, and it is the whole reason a restaurant moves from one shared tag to many.
Keep the mapping between identifier and table on the server. Tables get renumbered, moved together for a party of twelve, and put outside in summer, and every one of those is a change in a table of records rather than a walk around the room with a phone.
Write the tags on a bench before they go into their holders, which is the sequencing the writing page recommends, and verify every one by reading it back before service.
The tag that gets replaced
This is the risk that makes the case different from a menu. A tag in a public room can be covered by another tag, and the person who does it is not trying to read anything: they are trying to be the destination.
Nothing written on a tag prevents that, because the attacker supplies their own tag. What works is physical and procedural: a mechanically fixed holder rather than a sticker, a tamper evident construction where a sticker is unavoidable, and staff who look at the tags as part of setting the room, the same way they check the cutlery.
Print the domain beside the tag. A guest who can see where they are meant to arrive can notice that they did not, which is the advice the unknown tag page gives from the other side of the table.
And keep the destination on your own domain rather than a platform's, so that the address a guest sees is the name of the restaurant they are sitting in.
What the guest is being asked to do
Tapping an object in a public place and then entering card details is the exact pattern the security section warns people about, and a restaurant asking for it inherits that suspicion, as the terminal page describes.
So the page has to earn it in the first two seconds: the restaurant's name, the table, the amount, and a payment step that happens on a provider's page rather than in a form the restaurant wrote.
Ask for nothing else. A phone number for order updates is defensible; an account, a newsletter and a date of birth are what turn a convenience into a reason to call a waiter, and the disclosure page covers what the page should say about itself.
What happens when it does not work
A share of guests will not tap: an old phone, a flat battery, a setting turned off, or no interest. That share is not small, and the fallback page is about planning for it rather than hoping.
The answer is that ordering from the table is a convenience on top of a service that still works without it. A room where the only way to order is a tag is a room that loses covers on a bad signal day.
Watch the first service rather than the dashboard. Where guests hesitate, what they read first, and how many wave a waiter over anyway is the requirement, and it is visible in twenty minutes of standing quietly at the side of the room.
Frequently asked questions
What stops someone swapping the tag?
Nothing on the tag. A fixed holder, a tamper evident construction and a staff check before service are the defences, plus a printed domain a guest can compare.
Does each table need its own address?
For ordering, yes. That is the only thing the identity buys, and it is what lets an order arrive attached to a table.
Should the payment page be ours?
Show your name, the table and the amount, then hand the card step to a payment provider's page rather than to a form you wrote.
What if a guest will not tap?
Take the order the usual way. Ordering by tap is a convenience on top of a service that has to work without it.