For Logivision L-POS

Your lane keeps its POS.
The customer finally gets a screen worth reading.

A plug-in that installs into the L-POS you already run and turns the payment terminal into a second display for the sale. The cashier scans; the customer watches their own basket build in front of them, line by line, with the tax and the total moving as it goes. Press tender and the same screen takes the card — no second system, no re-keying, nothing new for anyone behind the counter to learn.

One sale, two screens

Watch it land on the other side of the counter.

This is the sequence the plug-in actually performs — a line pushed on every scan, a void that clears it from both screens, the display frozen the instant subtotal is pressed, and the approval walking back into the ticket. Sample basket, for demonstration.

An illustration of one sale. As the cashier scans, each line — description and price — is sent to the customer-facing terminal alongside a running tax and total; a voided line is removed from both screens. At subtotal the terminal display freezes, the terminal asks for a tip using the store’s presets, the card is tapped, and the approval returns to the point-of-sale ticket before the terminal shows a thank-you and returns to its idle screen.

The customer-facing screen

Between sales, that terminal is the best-lit thing on your counter.

Most of the day it shows nothing anyone chose. Here every state it can be in — waiting, ringing, refused, thanking — is a setting, and it returns to your idle screen by itself afterwards, without anybody remembering to put it back.

Idle

The screen between sales is yours

Write the line that sits on the terminal while the lane is quiet — a greeting, a promotion, the store's own name. It goes back up on its own after every sale, every hold, and every decline.

Decline

Your wording when a card is refused

A declined card is an awkward twenty seconds. Choose what the customer reads during it, and how long it stays up, instead of leaving them with a code.

Thanks

A thank-you that clears itself

After an approval the terminal says thank you, holds it long enough to be read, and returns to your idle screen without anyone touching it.

Reset

One key puts the terminal back

A function on the till clears whatever the terminal is showing and restores the idle screen — for the times a customer walks away mid-sale.

Cart

The live cart, on or off, per store

Show the basket as it is rung up, or don't. If you do, you choose how many lines stay on screen before the older ones collapse into a single running line.

Station

Set once, or set per till

The screen wording is shared across the store; the terminal, the tip prompt, and its presets are set per station — so the café counter can ask for a tip and the service desk never does.

Tips

Asked on the terminal. Never typed by your cashier.

A tip a staff member enters on someone else’s behalf is a conversation nobody enjoys and a number nobody can defend later. Move the question to the device in the customer’s hands, put your own options on it, and the awkward part disappears along with the argument.

See it on your own presets
  • The prompt happens on the terminal, in front of the person paying — your cashier never types a tip on anyone's behalf
  • Use the terminal's own defaults, or your presets: each one a name plus a fixed amount or a percentage
  • Calculate the percentage on the amount before tax, if that is your policy — one checkbox
  • Refunds never ask for a tip
  • The tip rides on the card charge and lands on the printed card block, so the drawer and the ticket agree

On the lane

Everything else stays exactly where the cashier left it.

The integration lives behind one tender button. What it changes is what happens after that button — and what comes back into the ticket when the card is done.

Tender is still one button

The cashier presses the payment key they already press. The plug-in takes the amount and the tax straight from the L-POS totals, starts the sale on the terminal, and hands the result back to the ticket — no second screen, no re-keying, no new muscle memory.

Split tender, with the balance shown

A partial approval doesn't strand the sale. The remaining balance goes back on the customer's screen and the next card picks up from there, with every approval recorded against the same ticket.

Voids and purchase corrections that hit the right payment

Every approval on a ticket is remembered by id. When that ticket is reversed later, exactly those payments are voided — not a guess based on amount and time.

Refunds, and a training mode that touches nothing

Refunds run from the same button. Training mode approves on the till alone, so a new cashier can be walked through a full sale without a terminal, a card, or a cent.

The card block prints on your receipt

Brand, masked card number, how it was read, the auth number, the approval line and the cardholder acknowledgement are composed into your L-POS receipt at the width it already prints. Merchant copy, customer copy, both, or neither.

Reports that name the right card

The brand that came back from the terminal is mapped to the matching L-POS tender code, so your end-of-day splits Visa from Mastercard from debit instead of piling everything under one line.

When it goes wrong

A lane is judged on its worst thirty seconds.

Anyone can demo a sale that works. What matters is the one where the network stalls, the customer walks off, or the cashier reaches for cancel a half-second after the card was tapped. Those cases were designed first.

01

The terminal's answer wins, always

A cashier cancels; a half-second earlier the customer tapped. The plug-in does not assume — it reads what actually happened and, if the card was charged, reports the approval to L-POS rather than letting a real charge vanish off the ticket.

02

The wait is visible, and interruptible

While the terminal has the customer, the till shows the amount, a live countdown against your configured timeout, and a cancel button. Nothing is frozen and nobody is guessing whether it is still working.

03

A timed-out sale doesn't leave a stuck terminal

If the sale runs past its timeout, the cancel goes out, the terminal is reset, and your idle screen goes back up — so the next customer meets a ready lane, not somebody else's abandoned payment.

04

It notices the terminal is gone before the queue does

A heartbeat checks the terminal on a set interval and warns the cashier on the till after a few consecutive misses. It steps aside during a sale and picks back up after. Better to hear it at 9:15 than from the front of a line at noon.

And where the line is.

Four things this integration does not do. Better here than in week two.

  • No offline mode. A card sale needs the connection — there is no store-and-forward queue, and we would rather say that than have you find out during an outage.
  • The customer screen is text. Your words, your timings, your cart — but not logos, images, or brand colours.
  • The card block prints on the L-POS receipt, on your existing printer. The plug-in does not print to the terminal's own roll, and does not text or email receipts.
  • Signature is not captured on the terminal in this integration, and neither are loyalty numbers or survey answers.

Getting it on the lane

An installer, one setting in the back office, and three fields.

No lane rebuild, no database migration, no weekend. The screenshots below are of the shipped configuration dialog — every switch described on this page is a box you can see in them.

  1. Run the installer

    It locates the L-POS program folder on its own and refuses to install anywhere else, so it cannot be dropped in the wrong directory by mistake. Removing it unregisters cleanly.

  2. Point the tender button at it

    In the back office, the payment tender is set to use a plug-in, named POSVelocitySEMI. That single setting is what puts the integration on the lane.

  3. Fill in three fields

    An app key, which terminal this till talks to — by label or by serial — and the service address. Timeout, heartbeat interval and logging are there if you want them, and sensible if you don't.

  4. Ring one sale

    Scan two items, watch them land on the terminal, tender, tap, and check the card block on the receipt. If those four things happen, the lane is done.

The dialog, as it ships

Idle and decline wording, how long a decline stays up, the live-cart switch and its line budget, and which receipt copies print.

Runs as
An in-process extension of L-POS on the till
Network
Outbound HTTPS only — nothing listens on the lane
Settings
Shared across the store, overridden per station
Diagnostics
An optional log file, per till, switched on when you need it
The Screen tab of the POSVelocitySEMI configuration dialog: welcome and decline screen messages, decline display duration, a checkbox to show cart items on the terminal during a sale with a maximum item count, and the payment-receipt selector.

Try it on one till

Put it on the busiest lane you have.

That is where a payment integration is actually tested — at the front of a queue, on a Friday, with a card that does not want to read. Book a walkthrough and we will set one lane up with you, or take the installer and start from the till you have open.