Returns and RMA
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.
The free tier refunds and exchanges directly at the register. PRO routes returns through a real RMA workflow - request, approve, receive, settle - and then collapses it for the counter, so the audit trail of a staged return meets the speed of a walk-in one.
The Lifecycle at the Register
A full RMA has four stations: the return is requested, approved, the goods are received and inspected, and the refund is settled. Online returns need all four because they happen days apart. At the counter, the customer and the product are both in front of you, so the register runs create, approve and receive as one step and goes straight to settling.
The cashier walks a five-step wizard: Select Items, Return Details, Refund, Confirm, Processing. Each returned line carries a reason (Wrong Item, Defective, Damaged in Shipping, No Longer Needed, Wrong Size/Color, Other), the condition it came back in, and its resolution (refund or exchange). All of it lands on the RMA in Magento, with a comment trail recording every step.
When the situation does call for stages (the customer will bring the product next week; the item needs inspection in the back), the register creates the RMA and leaves it open. The pending-returns inbox on the Orders tab shows every open return, oldest first - including returns the customer started online and walked into the store - and any register at the location can pick one up and finish it.
Partial Receive: Refund Follows the Request, Restock Follows the Goods
When fewer items come back sellable than were returned, the two quantities deliberately part ways:
- The refund follows the requested quantity. A customer returning 5 items is refunded for 5, even if only 3 survived inspection. The customer gave all 5 back; the refund is theirs.
- The restock follows the received count. Only the 3 sellable items re-enter stock. The other 2 are routed by their condition, not silently reshelved.
This is the honest split: inspection results affect your inventory, never the customer's money.
Where the Stock Goes
Receiving records each line's physical condition, and the condition decides the destination:
- Pristine items restock to the source they were sold from.
- Damaged items route to the damaged-stock source you configure, so they cannot be resold by accident. With no damaged source configured, they land on the location's main source with a stock note.
- Dispose writes the line off entirely.
The cashier can also override the destination per line - useful for a "to refurbish" or transit source - or opt a line out of restocking altogether, which the RMA records as a deliberate choice.
Where the Money Goes
Settling creates the credit memo in Magento and closes the RMA. The destinations:
- Original payment: web orders refund through the payment gateway (Mollie and others); the PSP refund reference is stamped into Magento's transaction records, so the refund shows in the admin's Transactions view and accounting exports like any online refund. Open pay-by-invoice orders settle as a credit note against the receivable - no money moves at the register.
- Cash or card at the counter: the RMA parks as awaiting refund, the cashier hands the money back through checkout (drawer pay-out or terminal reversal), and the settlement books the memo with the tender actually used.
- Exchange: the returned value credits the new sale in the same cart. When the exchange order places, the RMA closes automatically.
- Store credit: the refund lands on the customer's account balance instead. Requires an active store-credit provider and a registered customer; when no provider can issue credit, the wizard shows the option disabled with the reason rather than hiding it.
On top of the item refund, the wizard supports a goodwill adjustment (extra credit for the inconvenience), a restocking or handling fee (subtracted), and a shipping refund - each lands on the corresponding credit memo field, so the Magento books match what actually crossed the counter.
The Online-Refund Window
Payment providers stop accepting refunds against a payment after a provider- and method-specific window - anywhere from 90 days to a year or more, and some methods have no limit at all. When a return is older than the configured Online Refund Validity, the register shows a hint under the Original Payment and Terminal options: the provider may no longer accept the refund, while cash and store credit always work. It is a hint, not a gate - the option stays selectable, because the window differs per provider and per payment method, and the provider itself is the only authority. The same hint appears on the order-detail Refund sheet and on the return summary at checkout. The window is configured globally, can be overridden per location, and 0 turns it off.
RMA Backends
The staged workflow runs on an RMA provider, and exactly one is active per store:
| Backend | Ships as |
|---|---|
| Built-in POS returns | Included in the Hyva_Pos module, works out of the box |
Adobe Commerce RMA (Magento_Rma) |
Bridge: magento2-hyva-pos-adobe-commerce |
| Amasty RMA | Bridge: magento2-hyva-pos-amasty |
| Aheadworks RMA | Bridge: magento2-hyva-pos-aheadworks |
With a vendor bridge installed, the POS drives your existing RMA module - in-store and online returns share one system, one numbering, one admin view. One caveat that comes from the vendor modules themselves: they only accept returns on shipped items, so counter sales that never had a shipment are served by the built-in provider. Agencies can build a bridge for other vendors.
Configuration
- Stores → Configuration → Hyvä POS → Advanced → Credit & Return Providers → Return (RMA) Provider: pick the backend, or leave it on auto-detect - an installed vendor bridge wins over the built-in provider.
- Stores → Configuration → Hyvä POS → Terminal Defaults → Pickup Defaults → Damaged-Stock MSI Source Code: where damaged returns go. Overridable per location.
- On the register, the return flow is gated by the issue refunds permission on the staff role, so who may hand money back is a Magento decision, not a device setting.
Returns for sales made on another terminal, or before the device existed, work through receipt sync: the register reconstructs the receipt from the central archive.
Offline
Starting a return needs a connection - the order and the RMA live in Magento. If the connection drops after the cashier has already handed the money back, the server-side half (credit memo and RMA closure) queues on the device and completes on reconnect. Settlement is idempotent on the server: a retry after a timeout that actually succeeded is a no-op, never a second refund.