SHVA, EMV and In-Person Payments: What to Understand Before Connecting a POS

An in-person card payment in Israel involves five separate parties: the terminal, the terminal software, Shva as the switching node, the acquirer and the issuer. A business owner chooses almost none of them. What you do decide is the POS system, the terminal model, which acquirer you sign with, and who issues the accounting document.

Who does what in a card-present transaction

The row most people skip is the third. The reason the same error screens recur across different businesses, with different POS vendors, is that the software running the transaction on the terminal side is frequently the same software.

What is Ashrait, and why does it come up in every terminal conversation?

Ashrait is the card-clearing software Shva develops, and it is what runs inside terminals and computerised systems in Israel. Shva's own site lists it alongside the company's other services: 3DSecure for online transactions, a standing-orders solution, Shva TOP for taking payments on a smartphone, Shva CLP for closed-loop payment methods, and Shva Insights for financial data. Ashrait components are embedded in ERP systems and dedicated billing software too, not only in a standalone terminal.

The practical consequence for a development team: when the POS talks to the terminal, it is not inventing a protocol. It is talking to an existing component, at a specific version, configured against a specific acquirer. Those three things - component, version, configuration - are what you establish before writing a line of code, not after.

What does the business owner actually decide?

This is the short list, and everything else follows from it:

• Which acquirer you work with. That is the commercial decision, and it dictates which terminals and which transaction routes are even available to you.
• Which terminal. Fixed, mobile, or phone-based acceptance. The difference between them is operational - cellular coverage, battery, who holds the device - not a difference in your code.
• Which POS system. This is where most of the integration work lives, and where most of the faults live too.
• Who issues the document. The POS, the invoicing system, or another component. One transaction with two systems each issuing a tax document is the single most common failure in projects that join payments to bookkeeping.
• What happens on a refund. Voiding a same-day transaction and issuing a credit afterwards are not the same operation, and the distinction has to exist in the POS before it reaches an end-of-day count.

Which system is the source of truth - the POS or the terminal?

There has to be one answer, and it should be written down before the integration starts. The terminal knows what the card company approved. The POS knows what was sold. When the two disagree, one of them must win.

The pattern that works: the POS generates an internal sale ID before it contacts the terminal, and stores it. After the response it stores four fields - sale ID, terminal result, amount, and time. There are three possible outcomes, not two:

1. Approved. There is a positive response and a transaction identifier. Continue to the document and close the sale.
2. Declined. There is an explicit negative response. Offer the customer another payment method.
3. Unknown. Communication dropped, the terminal did not answer, or the response arrived truncated. Do not guess here.

The unknown state is the whole exercise. If the system renders it as "declined", the customer pays twice. If it renders it as "approved", goods leave without money. The fix is to mark the sale as pending and resolve it against the terminal or the daily close before the day is shut.

Where a POS-to-terminal link actually breaks

• Unsynchronised end-of-day. The terminal closes its day at one hour and the POS at another, and every comparison between them looks wrong without anything actually being wrong.
• Void versus credit. A void removes a transaction that has not yet gone to settlement; a credit creates a new movement. Implementing only one of them produces duplicate documents.
• Approved transaction, crashed POS. No document, no row, and the money is real. It surfaces only in reconciliation.
• A tip, discount or split payment added after approval. The amount at the terminal is no longer the amount in the POS.
• One terminal, two lanes. Two sales reach the terminal in an order nobody anticipated, and responses are matched to the wrong sale.
• Storing card details in the POS. Do not do this without explicitly defining with your acquirer and terminal supplier what is stored and where.

What to have ready before you talk to a developer

• The acquirer name and the transaction route, as they appear in the contract.
• The terminal model and the software version running on it.
• The POS or ERP product name, and whether a ready-made link to that terminal already exists.
• A written decision on who issues the accounting document.
• A description of the daily routine: who closes the day, when, and who compares the terminal report against the POS report.
• What happens for a refund that arrives a day later, a week later, and a month later.

This is a technical description of how responsibilities divide across a card-present chain, not advice. EMV, PCI and card-scheme requirements exist, and what applies to your business is settled in writing with your acquirer and terminal supplier.

Related: reconciling card transactions against your system, comparing Israeli payment gateways, automating payment to invoice.

Sources

• Shva - Automatic Bank Services, company site
• Shva - The Payments Arena, English site