A cash register with card payments: do not lose sight of the till

A cash register with card payments is not just a device that swipes a card. It has to connect the sale amount, the payment method and the record left at the end of the day. Before you choose a system, check who actually processes the payment, how you mark a payment on the register, what happens with a declined transaction and how you compare the report with the terminal without guessing.

What really needs to connect in a cash register with card payments?

The transaction at the counter looks like a single action, but behind it there are at least three records: the sale on the register, the approval on the card terminal and the transaction that will later appear at the card processor. If one of them is left without a match, the end of the day turns into a search. So the first question is not whether the terminal looks new, but whether the employee can tell at every stage what was approved and what was only typed in.

Build a process where the amount is created once as far as possible, and define what to do when the external terminal does not receive the amount automatically. In that case the employee needs to read the amount from the register, type it into the terminal, wait for approval and only then mark on the register that the sale was paid by card. If the terminal declined the transaction, do not mark it as paid. If the customer switched to cash, change the payment method in the record too.

This separation matters especially in a busy business. A customer is in a hurry, a new employee hears a beep and assumes everything went through, and four more people are already waiting behind. A short, clear procedure saves you checking a pile of slips later.

Start with a payment map, not a list of devices

Before you choose a cash register with card payments, write down for a week which payment methods really reach the counter: card, cash, app, voucher, credit or a combination. Do not assume the card is the whole story. A Bank of Israel survey published on 10 January 2024 (in Hebrew) found that debit and credit cards and cash were the most preferred and most common payment methods among the public in Israel, and that convenience and speed were among the main factors in choosing payment apps. This is a market picture, not a substitute for your own business data.

The map also needs to answer the edge cases. Can a bill be split between cash and card? How is a gift voucher recorded? Who may cancel a payment marked by mistake? What do you do when a customer shows an approval in an app but the money does not yet appear where you check? Every payment method needs a fixed name on the register, a defined approval step and a person who knows where to verify it.

Do not create five names for the same thing. If one employee chooses "credit", another "card" and a third "terminal", the monthly report tells three stories about the same income. Short, fixed names turn the report into a working tool and not a collection of corrections.

Five checks worth doing in a real transaction

The important check happens at your place, with noise, a queue and a product that needs to go back on the shelf. Run a small series of test transactions without charging a real customer, for example during the trial period. Go through these scenarios in order:

1. A regular card sale, including a full match between the amount on the register and the amount on the terminal.
2. A declined transaction, to see that the sale does not close by mistake as if it were paid.
3. A switch from card to cash after a decline, including correcting the payment method in the report.
4. A cancellation or return according to the business's procedures, with the right permission and clear records.
5. A split payment, if you really offer it, to make sure both parts appear correctly.

In each scenario, take a screenshot for yourself or write down the transaction number in the test environment, then go to the summary screens. Do not settle for a receipt that looks fine. Find the sale in the register report and the approval where the card processor shows it. The goal is not to prove that a system can swipe a card. The goal is to know that the team can reconstruct what happened even an hour later.

It is worth including the check in training a new employee. If they can explain out loud the difference between "the transaction was recorded" and "the payment was approved", your procedure is clear enough. If not, the shortcut is missing.

The terminal and the register do not have to be the same product

Many business owners look for one device that does everything, but the operational link matters more than the casing. You can work with a browser-based register and an external card terminal, as long as it is clear who is responsible for processing and how the transaction is recorded. As of 12 September 2026, the KupaLi home page makes clear that you keep swiping cards on your existing card terminal and mark the payment on the register. The agreement and fees stay with the card processor. The full price list also states that hardware and payment provider fees are not part of the software subscription.

Need a card terminal integrated in the system (₪1,500 + VAT, coming soon)? Until it is available, work with your external terminal.

This separation is not an automatic advantage or an automatic drawback. It simply requires you to check two things: how many times the amount is typed in each sale, and how a mismatch is found. If the employee types the amount in two places, add a visual check before approval. If the systems are linked, check what happens when the link drops and whether you can still see which side did not complete the action.

Do not accept a general promise that "everything syncs". Try a transaction, a decline, a payment method change and a return yourself. Four minutes of a real scenario are worth more than twenty slides.

The report to read at the end of the shift

A payment methods report needs to answer a simple question: how much of the sales was recorded in each channel. It does not replace the card processor's report, because each records a different point in the process. Compare the total card transactions on the register with the total approved transactions on the terminal over the same time range, then check exceptions one by one.

Approved screenshot from demo data from September 2026: payment method split and receipt totals. It is shown to illustrate the matching question, not to promise a result in a particular business.

If there is a gap, start with the likely actions: a transaction that was declined but marked on the register, a payment that went through on the terminal and was not closed as a sale, a return recorded on one side only, or a different time range between the reports. Do not start with blame. Start with a transaction number, a time and the name of the employee who handled it.

We have already published a separate guide on closing the register at the end of the day without fighting. Here the focus is different: not counting cash, but matching the sale record with the payment approval.

Permissions and a short procedure beat a good memory

Not every employee needs to cancel a transaction, change a payment method after the fact or make a return. Define who may do each action and what they need to record. A permission without a procedure leaves a manager with an action that was done but no explanation. A procedure without a permission leaves too many hands on a sensitive button.

Write one page, not a booklet. Start with four situations: the transaction was approved, the transaction was declined, the customer changed payment method and the customer asks for a cancellation or return. For each situation, give one action on the register, one action on the terminal and a person to turn to if something does not match. Hang the page where the team sees it but customers do not need to read it.

Then check the procedure once a month on a random transaction. Pick a receipt, find the payment and see whether the names and times connect. It is a small check that spots bad habits before they turn into a whole evening facing reports.

How to compare options without getting lost

When you test a system, score each option on real work and not on the number of features on the sales page. You can use a short table: the number of entries in a regular transaction, employee training time, handling a decline, permissions to cancel, clarity of the payment methods report and how you export the data you need. Add a column for the full monthly cost, including software, hardware, connectivity and fees that are not inside the subscription.

Do not compare one software price with the full price of another solution. Ask each provider to separate station, branch, equipment, installation, card processing and add-ons. If a certain number depends on turnover, card type or agreement, mark it as variable and do not put a guess in the table. That way a cheap offer stays cheap only if it really fits the way you sell.

Do the comparison with two employees: whoever closes the day and whoever spends most of the time at the counter. The first will see the reports. The second will see the unnecessary entry everyone will complain about after a week.

A ten-minute exercise before signing

Take a sample transaction of 137 shekels. Ask the seller to run it by card, get a deliberate decline in the test environment, switch to cash and then cancel the sale according to their permission. Measure only three things: how many times the amount was typed, how many screens were opened and where a record of each change remained. These numbers describe the counter experience better than the word "simple".

Then swap roles. Let a manager who did not stand at the register find the sequence of actions in the reports. They need to identify the sale, see that the card was not approved, understand that cash was received and find the cancellation. If they need to ask the seller what happened, a detail is missing in the report or in the procedure. If they find everything without a verbal story, you have a trail you can work with.

Repeat the exercise on the device and connection you will really use. A wide computer display does not prove that the right button will be clear on a small tablet, and a fast connection in the office does not simulate a busy stall. Write down the first problem you ran into and the recovery time. This is not a lab test. It is a short rehearsal of a moment the team will face precisely when the queue is long.

Before you decide

Five questions to check during the trial period

• Who approves the payment, and when does the sale count as closed?
• What does the employee do when the card is declined and the customer switches to cash?
• Where do you see the total card payments for the same time range?
• Who may cancel, refund or change a payment method?
• Which costs belong to the software, the hardware and the card processor?

A cash register with card payments is good for your business when it shortens the work without erasing the trail of the transaction. If the employee knows what was approved, the manager knows where to check and the reports use the same names, even a busy day stays clear. Before signing, run the test scenarios and write down the answers. That is the whole difference between a system that looks smooth and a process that really holds up at the counter.