Payments
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.
Four tenders: cash, card (through an integrated terminal or with a manual reference), pay by invoice, and split payments combining cash and card. Cash, card and split all work on the free tier; pay by invoice requires PRO. Which tenders appear at checkout is configured in Settings → Payments - on PRO the same set can be pushed from Magento and locked, in which case the register shows the methods as managed and Magento wins.
Cash
Tendering is quick-fill first: an Exact Amount button (in cash-rounding markets, "exact" means the rounded amount - the unrounded total is not payable in physical coins), a keypad for typed amounts, and a per-denomination counting sheet - the same counting UI the register open and close use, using the bills and coins you configure under Settings → Payments → Accepted Denominations. Change due is calculated as the cashier types and shown large on the payment panel and again on the success screen.
What it does with your data and hardware:
- The sale lands in Magento as a normal order under the offline Check / Money Order method, with the tendered amount and change recorded in the order comments, and a fully paid invoice created immediately.
- With Auto-Open Drawer on Cash Sale enabled, the drawer kicks automatically after every cash sale (an ESC/POS pulse through the receipt printer - works on both tiers, see printers and cash drawers).
- The movement is recorded in the register session, so the Z report and the drawer count reconcile.
- A no-sale drawer-open button sits next to the tender field for checking change mid-sale; it is permission-gated (managers and up by default on PRO) and logged to the shift report like any cash movement.
Two toggles in Settings → Payments shape the flow: Require Open Register blocks cash sales until the register session is opened, and the Cash Rounding picker sets the legal increment.
Cash Rounding
In cash-rounding markets (5-cent countries such as the Netherlands, Belgium, Finland and Ireland; and others like Denmark and Switzerland with their own increments) the cash amount due is rounded to the increment you pick (0.05, 0.10, 0.50 or 1.00) and the receipt shows the rounding as its own line. Only cash actually collected is rounded: card legs settle the exact amount, and the Magento order keeps the unrounded total, so accounting reconciles cleanly. The signed rounding delta is stored with the sale, so reprints and register reports agree on what the register really collected.
Card With an Integrated Terminal
With an integrated terminal the app drives the card machine: the amount appears on the terminal by itself, the customer taps or inserts, and the order is placed only after the provider confirms the payment. Mollie is integrated today, with more providers in development. The Magento order books under the provider's own payment method (for Mollie, mollie_methods_pointofsale by default) and the full card metadata - brand, masked number, authorization code, acquirer reference - is stored with the sale for faithful slip reprints.
Card With Any Terminal (Manual Reference)
No integrated terminal? Type the amount into your standalone terminal as you always have, and record the payment in the app with the terminal's reference number (optional). This always works, with any payment provider, on both tiers. The order books under Check / Money Order with the reference in the payment record and order comments - deliberately not under a provider method, because no provider transaction exists to refund against later.
Pay by Invoice
PRO
Pay by invoice requires PRO - it is gated by staff-role permission and, optionally, per-customer credit limits.
A trade customer takes the goods now and pays on account. The option appears at checkout when a customer is attached to the sale and the signed-in cashier's role grants it; with credit limits enabled, the customer's headroom shows as a chip that turns red before the cashier can overshoot it.
Configured in Settings → Payments → Pay by Invoice (or centrally in Magento, with optional locks):
- Magento Method decides which payment method backs the order: Check / Money Order (default), Bank Transfer, Purchase Order (optionally collecting a PO number at checkout, stored on the order), or the PRO-only POS Invoice method for a separate reporting bucket. The three stock methods must be enabled at Stores → Configuration → Sales → Payment Methods.
- Invoice Behavior decides what Magento does at placement: create an open invoice (default - the receivable is visible and you collect via the standard invoice email), create no invoice (invoice manually when you collect), or create a paid invoice (payment was actually collected at the register).
Split Payments
A sale can be paid part cash, part card. Enable Allow Split Payments in Settings → Payments (it stays a device preference even when Magento manages the method list), then at checkout the arithmetic is done for you: the cashier enters the cash received, and when it does not cover the total a Pay rest by card button offers the remainder - sent to the integrated terminal, or recorded with a manual reference.
Each leg is recorded separately on the Magento order: the payment record carries every leg with method, amount and reference, the invoice comment spells out the split, and the register report accounts for each tender in its own bucket - so the drawer count and the card settlement both reconcile.
A split order books under Check / Money Order (checkmo), never under the card provider's method - a sale half-paid in cash must not become a full-amount card order. The per-leg truth is stored on the payment record instead (Magento's payment_additional_information): a split_payment marker plus one entry per leg carrying method, amount and - for the card leg - the PSP transaction id. The card payment keeps its full identity: transaction id, dashboard link and card metadata all land on the receipt and the payment record, and a refund of the card leg still routes through the provider's API against that stored id, while the cash leg refunds from the drawer. Only a sale paid entirely on the terminal books under the provider's own Magento method (table below) - which is exactly what hands refunds and admin deep-links to the provider's native Magento module.
What Each Tender Records in Magento
Every tender produces a normal Magento order - it appears in the admin like any order, invoices and credit memos work, ERP and accounting integrations consume it unchanged. The differences are in the payment method the order books under and what the order comments say:
| Tender | Magento payment method | On the order |
|---|---|---|
| Cash | Check / Money Order (offline) | Tendered amount + change in the comments; paid invoice |
| Card, integrated terminal | The provider's method (Mollie: mollie_methods_pointofsale by default, configurable) |
Provider payment id + card metadata with the sale; paid invoice |
| Card, manual reference | Check / Money Order (offline) | Reference number in payment record + comments; paid invoice |
| Pay by invoice (PRO) | Your mapped method (checkmo, banktransfer, purchaseorder, or pos_invoice) |
Open, paid or no invoice per your Invoice Behavior setting |
| Split | As the split's card leg dictates | Every leg with method, amount, reference; invoice comment spells out the split |
| Zero-due | free |
"No payment collected" comment; order lands paid |
Every POS order is also flagged as register-origin in its payment information, so the back office (and any integration) can tell POS orders from web orders reliably. How the order itself is built - addresses, line items, why totals are exact - is covered in how orders are placed.
Zero-Due Sales
When store credit, a gift card, reward points or a discount covers the full total, the picker is replaced by a quiet "No payment due" card and the order is placed under Magento's zero-total free method, landing as paid rather than waiting for a manual invoice.
Refunds Go Back to the Original Tender - on Both Tiers
A refund offers the channels that match how the sale was originally paid, and the checkout shows the original payment breakdown so the cashier knows what is coming:
- Cash-paid: hand back from the drawer; the pay-out is logged against the register session.
- Terminal-paid: refunded through the payment provider's API directly from the register - the money returns to the customer's card. This works on the free tier too; it is not PRO-gated.
- Split-paid: the refund reconstructs the original mix - cash back from the drawer, card back through the terminal, each leg to where it came from.
- Manual-reference card sales are the one exception: there is no provider transaction to refund against, so the cashier reverses the payment on the standalone terminal by hand and confirms in the app.
Refund math (partial refunds, exchanges netting against new items) is the same engine on both tiers; see returns and exchanges. Store-credit refunds require a PRO credit provider.