What a browser crypto POS terminal does and doesn't do

A crypto POS terminal at Paymos is a web page, not a device. One terminal link per project, generated in the merchant dashboard, opens on a phone or tablet — no dedicated payment hardware, no per-device setup, nothing to pair. The cashier keys an amount in a fiat currency, from the 46 the terminal supports, and the screen resets once the payment confirms. It carries no inventory, no shifts, no receipt printing, no tax calculation, and no tipping.

That last sentence is the one a POS page normally omits. A capability list read at a desk becomes a promise tested at a counter, and the gap between them surfaces in front of a live queue.

The terminal product page makes the case for the capability and the documentation covers where the link comes from. What follows sits under both: the operating shape of a browser terminal, and the five edges it has.

What is a browser crypto POS terminal?

A browser crypto POS terminal is a checkout screen that runs as a web page on a device the merchant already owns. No dedicated payment hardware appears anywhere in it — a phone or tablet with a browser is the whole equipment list.

One terminal link exists per project, generated in the merchant dashboard. The cashier opens that link, and opening it is the setup: no device provisioning, no pairing step, and no piece of equipment that has to be registered before it can take a sale.

There is no switch behind the link. A project's Integration method is answered once at creation and is not editable afterwards, so a project connected as a terminal has one, and a project connected any other way has none. A merchant running three counters runs three terminal projects.

What does this terminal not do?

The terminal does not do inventory, shifts, receipt printing, tax calculation, or tipping. Those are five jobs a full POS system carries, and not one of them is present. So the list sits this high in the article, where a merchant reads it before a cashier discovers it mid-queue.

Publishing the terminal's list is the point. A product page states what a thing does, a reader takes the surrounding silence for coverage, and at a counter that misreading costs a sale — which is the one place worth inverting a feature list.

The terminal is a payment screen. It takes an amount and gets it paid, and the rest of the shop's floor stays wherever it runs today: the stock system, the rota, the receipt book, and whatever works out what is owed.

What changes when there is no hardware to pair?

Pairing is what turns a POS device into an object you buy, insure, provision, and replace. A browser terminal removes that step and the device inventory behind it — nothing to charge overnight, and no equipment that has to be present for a sale to happen.

Replacement follows from the same fact. A tablet that dies mid-shift is replaced by opening the terminal link on a different one, because nothing was ever bound to the broken device and no per-device setup has to be repeated on its successor.

The dependency moves; it does not disappear. A browser terminal needs a device with a working browser and a live connection, which is a different thing to worry about from a reader with a battery — not the absence of anything to worry about.

What does one terminal link per project cover?

One terminal link covers every device that opens it. Multiple devices can use the terminal, so a second cashier opens the same page on another handset, and a third does the same again — one link, however many hands are on the counter.

Every device inherits the same look. The terminal uses the project's checkout branding — the same name and logo, style preset, colours, and corner radius the project's payment pages already carry — so three phones behind one counter show one shop.

What a project-level link does not bring with it is a shift. The terminal has no object that opens under a named cashier and closes with a count, so day-end accounting comes from wherever it comes from now, on the procedure that already runs.

What does entering the amount in a fiat currency do?

Entering the amount in a fiat currency prices the sale in the money both parties think in. The terminal takes amount entry in 46 fiat invoicing currencies, so the number on the screen is the shop's own price, and nobody at the counter converts anything into a token quantity.

A terminal sale locks its rate at the moment the payer pays. From that point the stablecoin amount the payer sends does not move with the market, which is what a counter needs when the price was agreed out loud before anyone opened a wallet.

Fiat-denominated invoicing is not a terminal feature, though. An amount can be entered in a fiat currency on any invoicing surface, so a shop selling at a counter and online prices both the same way and reads one currency across the two.

Where do stock counts and shifts live instead?

Inventory and shifts are the two absences that surprise people most, because both read as POS defaults. The terminal carries neither: nothing decrements when an item sells, and nothing opens or closes around a cashier's working day. Both jobs stay where they sit today.

Stock is the clearer of the two. A system that tracks inventory needs the identity of the item sold; the terminal takes an amount, and an amount fixes a price while naming no product. Nothing in that number tells a stock list what to decrement.

Shifts are a container rather than a feature. A shift is a starting float, sales accumulated under one person, and a count at the end that either reconciles or does not. A payment screen with no shift object has nothing to open, so the day closes where it closed before the terminal arrived.

Where does the receipt come from if nothing prints?

A receipt obligation belongs to the seller rather than to the payment screen. The terminal prints nothing and issues no receipt, which changes who produces the document, not whether one is owed. Law stands behind this absence, and behind two more below.

Tax law sets it, upstream of any terminal. EU VAT invoicing rules put the duty on the business: it must issue an invoice "whenever goods or services are supplied to another business or a non-taxable legal entity", except on exempt supplies such as financial and insurance services. For private individuals an invoice "may be required" under national rules.

That obligation attaches to the supply, not to the rail the money arrived on. A shop owing a document owes it whether payment came by cash, by card, or by stablecoin at a browser terminal — one more way to pay.

The payment still leaves a record. A terminal sale is an invoice on the merchant's account, and the dashboard carries invoice search, filters, and invoice details — a record of what was paid, not a document for the customer.

Why is sales tax not calculated at the counter?

Sales tax is a jurisdiction question, settled well before the money moves. The terminal performs no tax calculation, and the reason is that the correct number depends on facts a payment screen never sees, at a counter or anywhere else.

US rates combine a state component with local ones. The Tax Foundation's 2026 edition puts the nationwide population-weighted average combined rate at 7.53% as of 1 January 2026, with individual states sitting well above and well below that line — a spread no terminal setting stands in for.

An average is not a rate anyone charges. What is owed turns on where the sale happened, what was sold, and who bought it — three things the terminal never asks, and a wrong answer to any of them surfaces months later, in a filing.

So the terminal takes the number the shop's own tax handling produced. That calculation sits upstream, where the product and the address are both already known, and the amount reaching amount entry is the total the customer has been quoted.

Why is a tip line not a payment-screen feature?

A tip is a payroll object with a reporting chain behind it. The terminal has no tipping, and a tip line would put the front of that chain on a screen that cannot carry the rest — a collection point with nothing downstream.

Law sets that threshold, and no terminal setting moves it. Employees receiving $20 or more in cash tips in a calendar month must report the total to their employer in writing, by the tenth day of the next month. "Cash tips" includes charged tips the employer distributes, so a digitally paid tip counts.

A tip collected at a terminal has to reach that report. It needs attributing to a named employee, accumulating across a month, crossing the threshold, and landing in payroll — and a terminal with no shifts and no staff records holds none of that.

Absence is the honest answer here. A tip line collecting money nobody can attribute is worse than no tip line at all, because it creates an obligation with no record behind it, and the terminal offers no such line.

What happens after a payment confirms?

The terminal resets after a confirmed payment. The screen returns to amount entry, so the next sale starts from a cleared amount with nothing left over from the last customer, and the cashier taps nothing to get the screen ready.

Confirmed is a defined state rather than a hopeful one. How deep a payment goes before the terminal calls it confirmed follows from the network and the amount together — a small sale can clear at a shallower depth, a large one can require a stronger threshold, and why the wait varies sets out the policy in full.

That is why the reset is worth naming as behaviour. The terminal is not choosing a moment to move on: the reset follows the confirmation, which makes the cashier's cue to hand over the goods and the screen's cue to clear the same single event.

Which counters does a browser terminal suit?

A browser terminal suits a counter whose records already live somewhere else. Market stalls, pop-ups, service businesses, and any till where a sale is a price and a payment, with no line item pulled out of stock. A payment screen is the only piece those counters were missing.

The same list reads as a disqualifier in the opposite case. A shop whose stock levels move as items sell, a restaurant where servers are paid partly in tips, or a jurisdiction requiring an issued document at the point of sale each needs a system the terminal is not.

Both readings come out of one list, which is the argument for publishing it. Decide whether a browser POS terminal is the piece that was missing — the ways to take crypto online covers the case where it was not, and how an invoice reaches paid covers what the counter is doing while the customer's wallet is open.