Payments

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 comes from Magento (Stores → Configuration → Hyvä POS → Payments → POS Payment Methods) and can be locked, in which case the register shows the methods with a lock and a Magento badge.

Cash

Tendering is quick-fill first: an Exact Amount button (in cash-rounding markets, "exact" means the rounded amount, since the unrounded total is not payable in coins), a keypad for typed amounts, and a per-denomination counting sheet, the same one the register open and close use, with 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 with the tendered amount and change recorded in the order comments, and a fully paid invoice created immediately. With module 1.2.0 or later it books under the offline Cash (POS) method (pos_cash), changeable under Stores → Configuration → Hyvä POS → Payments → POS Payment Methods → Cash Method and per location. On the free tier it books under Check / Money Order.
• With Auto-Open Drawer on Cash Sale enabled, the drawer kicks automatically after every cash sale (an ESC/POS pulse through the receipt printer, 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 offers no tender at all until a register session is open, refund hand-backs and layaway payments included, 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 the cash collected is rounded: card legs settle the exact amount, and the Magento order keeps the unrounded total, so accounting reconciles. The signed rounding delta is stored with the sale, so reprints and register reports agree on what the register 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 and PAY. are integrated, sales and refunds both, with Adyen and Stripe in development. The Magento order books under the provider's own payment method (by default mollie_methods_pointofsale for Mollie and paynl_payment_instore for PAY.), and the full card metadata (brand, masked number, authorization code, acquirer reference) is stored with the sale for slip reprints.

Card With Any Terminal (Manual Reference)

Without an integrated terminal, type the amount into your standalone terminal and record the payment in the app with the terminal's reference number (optional). This works with any payment provider, on both tiers. The reference goes into the payment record and the order comments. With module 1.2.0 or later the order books under Manual Card (POS) (pos_manual_card), changeable under Stores → Configuration → Hyvä POS → Payments → POS Payment Methods → Manual Card Method and per location; on the free tier it books under Check / Money Order. It never books under a provider method, because no provider transaction exists to refund against later.

Pay by Invoice

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 remaining credit shows as a chip, which turns red when the sale would exceed the limit.

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 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). At checkout 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), not under the card provider's method. The per-leg detail 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 payment provider's transaction id. The card payment keeps its own details: 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 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:

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. How the order itself is built (addresses, line items, totals) 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 "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:

• 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.