Global Settings

Stores → Configuration → Hyvä POS holds everything that applies chain-wide. It has five sections: General, Terminal Defaults, Payments, Lock Settings and Advanced. Locations inherit these values and can override most of them per store, field by field.

How Settings Reach Devices

Registers pick up changes through their heartbeat: the device checks in every 5, 15, 30 or 60 minutes (a device setting, default 15), compares a configuration hash, and pulls the new configuration only when something changed. Expect a change to reach devices within minutes, not instantly. If a change never arrives, Magento cron and the heartbeat interval are the first two things to check.

General

• Version: the installed module version and update check.
• Hyvä POS License Connection: the API Key and API Token generated on your hyva.io account (see buying and licensing). The token is stored encrypted. With these set, the module fetches your licenses (a cron job syncs automatically; the Fetch Licenses button on the Licenses grid syncs on demand, right after you bought a new terminal) and renews license tokens.
• Enable POS: master switch for the POS system.
• Require Staff Login: the app must require staff PIN login before the register can be used. This is enforced from Magento: the app cannot bypass login even if someone disables it locally.
• Require Terminal Registration: devices must be activated on a registered terminal to operate; unregistered devices are locked out. Deactivating a terminal in the admin locks the device within its next heartbeat, for example when a device is stolen or an employee leaves.
• Default POS Order Status: the order status POS orders are created with.
• Share Held Carts: held carts are shared between all terminals at the same location, so a sale parked on one register can be recalled on any other. See held carts.
• Custom Sale Product SKU: the catalog product free-entry register lines are booked against. The module installs it as POS-CUSTOM (virtual, not visible, no stock); the line keeps the name and price the cashier typed. Change it only if you moved the product to another SKU.

Terminal Defaults

Chain-wide defaults every location inherits unless it overrides them on its own edit screen.

Receipt Defaults: the fields follow the printed receipt top to bottom:

Checkout Auto-Print: three independent switches for what prints automatically on checkout success: the customer's order receipt, a CUSTOMER COPY terminal slip, and a MERCHANT COPY terminal slip (with EMV audit fields). Each is its own print job: auto-cut printers cut between them, tear-off printers prompt for tear-and-continue.

Walk-in Customer Defaults: the name, email and address stamped onto sales booked without a registered customer, and the Customer Group (default NOT LOGGED IN) such a sale is priced and booked under. The group decides which catalog price rules, cart price rules and tier prices apply at the register, and the order lands in Magento with it, so a store that prices the counter differently from the webshop gives it a group of its own. Name defaults to "POS Customer"; empty email, phone and address fields fall back to Stores → Configuration → General → Store Information. Overridable per location.

Customers → Customer Validators: which checks run on a customer the cashier creates or edits at the register. Required fields and email uniqueness always run and are not in the list; the rest of the list is every validator installed, including the ones bridge modules add. Empty, the default, runs all of them. Pick one or more and only those run, next to the two that always do. See customer validators for what a validator can check and how a bridge adds one. Allow Guest Checkout (default Yes): whether a register may take payment without a registered customer on the sale. With No the cashier attaches or creates a Magento customer first, and the walk-in customer defaults do not count. Overridable per location.

Layaway Defaults: the layaway guardrails: Minimum Deposit (%) (default 25), Expiry (days) before a layaway is flagged stale (default 30), and Cancellation Fee (%) retained from the deposit on cancellation (default 0).

Pickup Defaults:

• Auto Ready: Backorder Pickup: backorder shipments flip to Ready automatically as soon as stock arrives at the source (checked every 5 minutes by cron).
• Auto Ready: Online In-Store Pickup: online pickup shipments flip to Ready on creation.
• Post-Pickup Order Status: the order status applied when a pickup is marked collected at the register; empty keeps whatever Magento set.
• Default Pickup Queue Filter: the filter the register's pickup queue opens with (all / ready / awaiting stock / stale). The queue is scoped to the location's MSI source. The ready-count badge on the register's Pickup tile uses opt-in polling configured on the device itself, not here.

Shipping Defaults → Counter Sale Shipping Method: the shipping method a sale the customer walks out with books under. Such a sale has no shipment, so the register sends none and the module stamps this method when the order is saved; an ERP that maps orders on the shipping method then has a code to map. The default is the module's own hyvapos_counter. In-store pickup is not offered here: the pickup queue selects on that code, and a counter sale is not waiting to be collected. Overridable per location.

Returns Defaults → Damaged-Stock MSI Source: the MSI source damaged-condition RMA returns are booked into. "-- None --" falls back to the location's main source with a stock comment.

Customer Prices → Fetch Customer Prices (default Disabled): per-customer prices come from the customer-price resolver pool (customer-group tier prices, Adobe Commerce B2B company prices, and any vendor price bridge), and PRO terminals fetch them for carts with a customer attached. "When added to cart" resolves one product per add. "While browsing the catalog" also prefetches every product tile on screen, one resolver-pool request per catalog page, which is heavier when a price bridge calls an external system. Locations inherit this default.

Tax Features: the tax overrides the register offers on a sale; the calculation itself follows Sales → Tax. Reverse Charge (EU) shows a reverse-charge switch for a customer with a VAT id: the sale is charged without VAT and the order is marked reverse charged. Tax Exempt Sales shows a tax-exempt switch so a cashier can sell an eligible order without VAT. Both default to No.

Stock → Default Low Stock Threshold: at or below this quantity the register shows a low-stock warning before selling. Use Multi-Source Inventory (default Yes): whether registers read and write stock per source through Magento Inventory: source-specific stock badges, the source picker, per-source stock edits, and shipments that name a source. With No the register uses Magento's plain stock figures and never calls the Inventory routes. On a store without the Magento Inventory packages it is off whatever it says. Overridable per location.

Promotion Rules → Fetch Missing Promotion Attributes (default No): the register evaluates cart price rules itself, from the product attributes in its cache. With this on, a register whose cache has no value for a rule's condition requests that product from Magento once per shift, one request per unknown SKU. With it off no requests are made; the rule applies from the cached attributes only and the cashier is informed when a rule cannot be checked. Locations can override it, and Lock Settings can enforce it.

Payments

• Register Session → Require an Open Session (default Yes): every sale, refund and layaway payment at a register books into an open session, which the X and Z reports total. With Yes a terminal offers no tender until a session is open, whether or not it accepts cash. Terminals can override it unless it is locked.
• POS Payment Methods: which tenders (Cash, Card / Terminal, Pay by Invoice) are enabled by default for new locations. Empty allows all.
• Allow Store Credit (default Yes): whether registers offer store credit in the Discounts panel. With a store credit provider configured (Adobe Commerce's customer balance, or one of the bridges) that is the customer's balance; without one, and on the free tier, the cashier enters a credit or voucher by hand, which is not checked against Magento. Overridable per location and lockable under Lock Settings.
• Cash Rounding (default Off; 0.05, 0.10, 0.50 or 1.00): the step a cash total is rounded to at the register, for markets that no longer hand out 1 and 2 cent coins. The order keeps the exact total; the rounding is recorded on it.
• Cash Method (default pos_cash): the Magento payment method a register's cash sale books under. The module applies it when the order is saved, so cash at the counter has its own row in reporting and in an ERP that maps on the payment method. Pick checkmo to keep booking cash the way earlier builds did. A location can override it on its edit screen.
• Manual Card Method (default pos_manual_card): the Magento payment method a card sale the cashier confirmed by hand books under, a card taken on a terminal the register does not drive. A card a supported terminal took keeps its provider's method, set under Card Payments. Pick checkmo to keep booking hand-keyed cards the way earlier builds did. A location can override it on its edit screen.
• Card Payments → Mode: Manual (no terminal integration; the cashier confirms the transaction), Mollie (payments sent to a physical Mollie terminal) or PAY. (payments sent to a PAY. terminal or a PAY.POS phone through Cloud Connect).
• Card Payments → Mollie: the Organisation ID, live and test API keys, and Mollie Test Mode. Magento Payment Method (Mollie) maps Mollie-routed card sales to another Magento payment method when the order is saved. The default, Mollie POS, is the Mollie module's own point-of-sale method, which gives the order refunds, dashboard links and webhook status updates; see the Magento payment method.
• Card Payments → PAY.: the Token Code (AT-…) and its API Token, stored encrypted, from my.pay.nl under Merchant, API tokens; the Sales Location (SL-…) the orders belong to, or empty to use the one linked to the selected terminal; and Test Mode, under which orders are not sent to the terminal. With the Sales Location Secret set, the register answers PAY.'s test page itself and the cashier picks the outcome on the register; without it the page opens and asks for the secret. Magento Payment Method (PAY.) works as Mollie's does: sales arrive under paynl_payment_instore, PAY.'s own in-store method, and a store that books them under another method picks it here. Registers on PAY. receive these values on their next configuration check; a location can override them on its edit screen, and a single terminal can override Mollie Test Mode and PAY. Test Mode (see per-terminal overrides).
• Pay by Invoice: Method chooses the backing Magento payment method: Check / Money Order (default), Bank Transfer or Purchase Order (all must be enabled under Stores → Configuration → Sales → Payment Methods), or POS Invoice, a Hyvä-shipped POS-only method that keeps these orders in their own reporting bucket. Invoice Behavior controls what happens at checkout: create an open invoice (the default; the receivable is visible in admin and is marked paid later), create no invoice, or create a paid invoice. Use Customer Credit Limits gates the feature by the customer's hyva_pos_credit_limit attribute. See pay by invoice.
• Refunds → Enable Built-in Refund: show or hide the standalone Refund tile on the register's order-detail screen. Hide it when an external RMA module owns your refunds and cashiers should refund exclusively through the RMA wizard.
• Refunds → Online Refund Validity (days): how long after payment the original payment method is assumed refundable through its payment provider. Refund windows are set by the provider and differ per provider and per payment method, from 90 days to a year or more, and some methods have no limit at all, so check your provider's documentation. The default is a conservative 120 days. Once the window has passed, the register shows a hint on the "Original Payment" and "Terminal" refund options. It never blocks them, because the provider is the authority and a store running several providers may find another one still accepts the refund. Set 0 to turn the hint off. Locations inherit this default and can override it per store.

Lock Settings

Every pushed default can be a suggestion or a rule. Lock Settings holds a Yes/No lock per field: a locked field arrives on the register as managed: the control shows a badge and is disabled, so a locked setting cannot be changed on an individual register. All Locks → Set All Locks flips every lock on the page at once; review and save the configuration afterwards.

Advanced

• Credit & Return Providers: when multiple credit / gift-card / reward / RMA modules are installed, pick which one the POS uses per feature: Store Credit Provider, Gift Card Provider, Reward Points Provider and Return (RMA) Provider. Only installed and enabled bridge modules appear in each dropdown. The RMA provider's "-- Auto-detect --" uses an installed vendor bridge when present and falls back to the built-in POS returns flow; vendor RMA applies to shipped items, in-store sales without a shipment always use the built-in flow.
• Credit & Return Providers → Revoke Earned Points on POS Refund (default No): when a POS order is refunded, take back the loyalty points that sale earned, in proportion to the refunded share and capped at what is still deductible. The reward-points bridge carries it out; a deduction entered by hand on the admin credit memo takes precedence.
• Customer Validation → Let Cashiers Save Over Warnings (default Yes): validators that answer "warning", "info" or "normalize" are shown for review and the cashier can save anyway. With No, warnings block the save the way errors do. Validators that answer "error" block either way.
• Self-Checkout: parameters for the customer email one-time-code sign-in on self-checkout kiosks: code length (default 6), validity (default 180 s), wrong-attempt limit (default 5), resend cooldown (default 30 s), and per-email / per-terminal hourly rate limits (5 / 20).
• Telemetry & Diagnostics: optionally collect anonymous diagnostics from your devices, such as which devices run low on memory, which API requests are slow. Off by default. Force Enable on Terminals removes the device-side opt-out (a notice is shown in the app's settings). Upload hour, raw-data retention (90 days) and aggregation window (7 days) are configurable; the data is browsable under Hyvä POS → Operations → Telemetry.
• Fiscal Data Export: how often DSFinV-K + TAR exports are generated from fiskaly: daily, monthly, or both (recommended). Failure Notification Email receives one message when a terminal's fiskaly export has failed five times in a row, and the next one only after a successful export starts a new streak; separate several addresses with commas. Empty sends no email; every failure is logged either way. See fiscal compliance.

Scheduled Jobs

The module registers eight cron jobs on Magento's default cron group:

If cron is not running, licenses eventually fail to renew and exports stop appearing.

Troubleshooting

• Fetch Licenses fails or the grid stays empty: the API key or token is wrong, or belongs to a different store on hyva.io. Re-enter both and save before retrying.
• A setting change never shows up on the register: wait one heartbeat interval, then check the terminal's Last Seen At on its edit form. A stale timestamp means the device is not checking in (asleep, offline, or app closed), and the setting arrives at the next heartbeat.
• A cashier keeps changing a setting back: that field has no lock set. Enable the matching lock under Lock Settings; the register's control turns managed at the next heartbeat.