Skip to content

How Orders Are Placed

Hyvä POS is in closed beta

Hyvä POS is currently in a closed beta (pilot phase) with a small group of merchants. It is not yet generally available: the App Store release follows the pilot, and features and configuration may still change - possibly in backwards-incompatible ways - before the general release. Want to take part? Sign up at hyva.io/pos.

Magento's own storefront builds every order from a quote: a server-side cart that Magento re-prices on every change and finally converts into an order. Hyvä POS deliberately does not do that. The register builds the cart on the device and places the finished sale directly through Magento's order API. This page explains why, and what that choice means.

Why Not Quotes?

A quote needs the server for every step: add a line, change a quantity, apply a discount, each a round-trip. That model has three problems at a register:

  • Speed. A cashier scans several items in a few seconds. A counter that waits on the network between scans is a counter with a queue.
  • Offline. A server-side cart cannot exist without the server. The offline queue that keeps a PRO register selling through an outage is impossible in a quote model; there would be nothing to queue.
  • Authority. At a physical counter, the register is the point of truth: the customer paid the amount on the receipt and left. A server that re-prices the cart afterwards cannot change what happened at the register. The order must record the sale, not recompute it.

So the app prices the cart on the device, using Magento's own data (prices, tax rules, tier prices, cart rules, all synced or evaluated live), completes the sale, and sends the finished order to Magento in one call.

What This Gives You

  • Instant registers: scanning, discounting and totalling never wait on the server.
  • Offline sales (PRO): the finished order waits in the queue; the sale itself was never interrupted.
  • Safe retries: every sale carries a unique id, so a retry after a network hiccup returns the existing order instead of creating a duplicate. See local receipts.
  • A truthful record: the Magento order carries the exact amounts from the register, line by line, tax by tax, matching the receipt the customer holds.

The Trade-Offs

Direct placement means Magento stores the order as sent rather than recomputing it, and that has consequences worth knowing:

  • Tax configuration must agree. The device calculates tax with the store's rules. On the free tier you configure the tax settings in the app to match Magento; on PRO they sync from Magento automatically, and the daily receipt-vs-order comparison exists to flag the rare mismatch (a changed tax rule, a one-cent rounding difference) so you can resolve it deliberately.
  • Coupons validate at apply time. When a cashier applies a coupon, the app validates it against Magento's cart-rule engine live. The resulting discount and the coupon code are recorded on the order; Magento does not re-run promotion rules at save time.
  • Complex product types are simplified. Configurable products are placed as the chosen variant. Bundles are placed as their component products with the bundle price distributed across them, because Magento's order API cannot represent a bundle's parent-child structure; stock and shipments stay correct, and the receipt still shows the bundle as sold.
  • Payment does not flow through Magento. The terminal talks to the payment provider directly; the order records the tender. There is no Magento payment-gateway transaction to capture later, which is correct for a register (the money already moved) but different from online orders.

Everything else about the order is ordinary: it appears in the admin like any order, invoices and credit memos work, ERP and accounting integrations consume it unchanged.