A card reader alone is not a complete service workflow
The guests are ready to leave, several people want separate bills and a server reaches for the card terminal. At that moment, the ability to read a card is only one part of the job. The open bill needs to be correct, the right guest needs to pay and the team needs a reliable answer about what has actually been confirmed. Mistakes often happen between checkout and terminal while new orders are arriving. Bonzumo helps you treat the order, table, amount and payment status as one connected process. The availability of a specific terminal connection has to be checked for your device, provider and setup.
Start your planning with the way service works, rather than with a device specification. Are payments taken at tables, at a counter or in several areas? Do guests often split bills, leave tips by card or ask for an invoice with business details? A small café with one fixed checkout needs a different handover from a restaurant with several service sections. Once those paths are clear, you can sensibly decide where terminals belong, who may use them and what connection to the POS is actually required.
Confirm the amount and the guest's request first
A common difficulty comes before any card is presented. A group wants to pay separately, but the items have not yet been assigned. Or a guest asks for a company invoice only when the terminal is ready. Give the team a simple sequence: check the right table and items, clarify the split and receipt request, then confirm the amount to be charged. Bonzumo includes the relevant table, bill-splitting, tipping and invoice flows. They are useful when the underlying decision has first been made clearly with the guests.
At a busy counter this check can be short, but it still matters. State the amount before starting payment. If an item has been added or changed, make sure the displayed total belongs to the current sale. Three training examples work well for a new colleague: a single coffee, a group at a table and a collection order with an extra item. The exercise teaches them to recognise the transaction in front of them, instead of pressing the same sequence of buttons from habit.
Requested does not mean paid
A card transaction can move through several states in quick succession: an amount is prepared, passed to a device, approved by the guest and processed by the payment provider. If a response does not arrive, an open screen cannot establish success or failure. This distinction matters in a restaurant. Repeating an uncertain attempt may charge the guest twice; closing a table too early may hide money that is still due. The team should act on a visible, confirmed payment status and pause when that status is unclear.
Agree on ownership for uncertain transactions. The server records the table, time, amount and step involved, and asks an authorised colleague to check the available checkout and terminal information. Only then should someone decide whether to retry or offer another way to pay. You can tell the guest plainly that the confirmation is being checked. It is more professional than a guess. Ask to see exactly this interrupted journey in a demo, because it says more about day-to-day suitability than a flawless sample sale.
Handle tips and partial payments deliberately
One guest may ask to add ten percent, another may name a rounded total and a third may choose not to tip. Bonzumo has paths for entering a tip, choosing a percentage and paying without a tip. Before confirmation, the team needs to see whether the displayed amount is only the bill or already includes the voluntary extra amount. With a split bill, that question applies to each payment. Do not silently apply one person's preference to everyone else at the table.
After each payment, check what part of the table is complete. If three guests pay separately and the first has used a card, the open work is not simply two names; it consists of particular items or shares. That remaining balance matters more at a handover than anyone's memory of the conversation. A training scenario with different payment methods and tip wishes shows whether colleagues read the same screen in the same way. Rules for distributing tips within the team and their accounting treatment need their own business-specific decision.
Choose the device and network for the actual room
Tableside card payment improves service only when the physical workflow fits the venue. Check whether a terminal travels between dining areas, whether outdoor tables have connectivity and where a receipt may be needed. A bar may work well with one fixed payment point; a large restaurant may need another arrangement. Charging stations, wireless coverage, device access and the way colleagues share a workstation all affect the result. Those practical details often matter more to speed than a long list of technically possible payment methods.
Check Bonzumo against your actual terminal model and payment provider. Record the model, software version, network conditions and existing service contracts. During setup, ask for a complete demonstration from the POS amount to confirmed payment and receipt. A terminal shown on another vendor's website is not a promise about your configuration. If automatic amount transfer is unavailable, the manual step must be clear and checked. The important outcome is a payment route your team can perform reliably during service.
Think beyond the guest's payment to the daily close
For a guest, a card payment ends with confirmation. For your business, it matters again at closing. The shift lead needs to understand which card payments belong to which sales, where a transaction is still open and whether a difference between checkout and provider information needs investigation. Bonzumo has closing and reporting contexts for payment methods and transactions. Reconciliation with a particular provider depends on the configured connection. Keep individual confirmed payments, grouped provider payouts and unresolved questions distinct.
If two shifts share a terminal, a brief status check belongs in the handover. Are any payments still uncertain? Was a transaction stopped because no response arrived? Who owns the next check? A short, traceable note is more useful than saying that the register was behaving oddly. Include a transaction that starts before a shift change and is reviewed afterward in the demo. This will show whether servers and managers have a common basis for their next decision.
Introduce card payments with real restaurant examples
You need only a few well-chosen practice cases to prepare a launch. Use a quick counter sale, a table with several payers, a card tip and a bill that needs invoice details. Add one deliberately interrupted attempt. For every case, show the current amount before payment and the confirmed status afterward. A colleague should be able to explain what portion is the sale, what portion is a tip and what remains open. This tests the guest's complete journey, not just how easily a terminal accepts a card.
Write down what causes trouble today. Do servers wait for a free device? Do they type the same amount twice? Does someone have to search for a receipt? Does an uncertain attempt get lost between shifts? These observations give the setup a practical starting point. Bonzumo can then be demonstrated against your actual service. You gain a sounder basis for device choice, roles, training and rollout order than a general promise about fast card payment.
Finally, look at the experience from the guest's side. Is the amount spoken clearly before the card is presented? Can a request to split the bill still be handled at the right point? When confirmation is missing, can the server explain calmly why they need to check before trying again? Test these questions with your own team in your actual dining rooms. Finish the introduction with a short written sequence for both the normal transaction and an unresolved one. New colleagues should be able to follow it during training without relying on the memory of a single experienced person.
Your managers need a matching routine. Decide who can investigate an uncertain terminal response, where a colleague records the relevant table and amount, and how the result is passed to the next shift. Include the receipt or invoice request in that handover when it matters. If a guest has left, the record should still let the authorised person understand what happened without guessing. A payment process feels simple to guests when the work behind it is organised: clear responsibilities, a visible status and a careful decision before anyone asks for money a second time.
This preparation is valuable even if you later change provider or add another terminal. The venue still needs to know where payments start, how a total reaches a device, what counts as confirmation and what happens when the link breaks. Bring that written flow into a Bonzumo demonstration and ask which steps the proposed configuration supports directly. Where an external device or contract is involved, record the exact open questions. That gives you a useful implementation decision instead of assuming that every card reader works in the same way.
