An online checkout and a shop counter take card payments in completely different ways, and the difference is not a detail. Online, the customer types a card number into a form. In person, the card is present: it is tapped or inserted into a certified terminal, and the terminal — not your website — handles the card data.
That distinction determines which payment methods you can accept at a WooCommerce POS, what you pay in fees, and how much of PCI compliance lands on you.
Card-present versus card-not-present
Card-not-present is your normal WooCommerce checkout: no physical card, higher fraud risk, higher fees, chargeback liability sits with you. Card-present is a chip, tap or swipe on a certified terminal: lower fraud risk, lower fees, and for chip transactions the liability for counterfeit cards shifts away from you.
Two consequences follow, and they surprise people.
- Your online gateway is the wrong tool for the counter. Typing a customer’s card into your website while they stand in front of you is a card-not-present transaction. It works, it costs more, and it puts the chargeback on you.
- Card-present payments need certified hardware. There is no way to accept a chip card with software alone. The terminal is not an accessory; it is the thing doing the payment.
The terminals OpenPOS supports
Stripe Terminal
The natural choice if you already take payments online with Stripe, because in-store and online sales land in the same dashboard and the same payout. The register sends the amount to the reader, the customer taps, and the result comes back to the register. Readers range from a pocket-sized card reader to a countertop unit.
Square Terminal
Well-known hardware, straightforward pricing, and widely available. A good fit if your customers or your accountant already expect Square.
Authorize.net, BlockChyp, Clearent and Vipps
Supported for shops with an existing merchant relationship, particularly in North America, and Vipps for the Norwegian market. If your acquirer is on this list you keep your rates and add the register.
LayBuy
Buy-now-pay-later at the counter, which is a meaningful conversion tool for higher-ticket retail.
Split and mixed payments
An online order has one payment. A counter order frequently does not: sixty in cash, the rest on a card; two friends each paying half; a gift card covering part of the total.
A POS therefore has to hold several payments against one order and only close it when they add up. OpenPOS supports mixing cash, card and wallet on a single order. This sounds obvious and it is one of the sharpest differences between a real POS and a WooCommerce checkout wearing a POS costume.
The practical detail: give your staff a workflow for a card decline halfway through a split. The order stays open, the cash payment already recorded stays recorded, and they retry the balance. A POS that voids the whole order on a decline will cost you a sale a week.
Cash is still a payment method
It is easy to design a POS around cards and treat cash as an afterthought. Cash needs its own machinery: a float at open, change calculation, a drawer that opens on cash sales but not on card sales, pay-ins and pay-outs during the day, and a count at close that produces a variance figure.
If the POS you are evaluating has a “cash” button and nothing else, your till will not reconcile and you will not know why.
What about PCI compliance?
Not legal advice, but the shape of it is worth understanding. When card data never touches your server — because a certified terminal reads the card and talks to the processor directly — your scope shrinks dramatically. That is the entire architectural argument for card-present terminals over typing numbers into a form.
Because OpenPOS is self-hosted, your WooCommerce database holds orders, customers and stock. It should never hold a card number, and with a supported terminal it does not. Run HTTPS everywhere, keep WordPress and your plugins updated, and give staff individual logins. Ask your acquirer which self-assessment questionnaire applies to you.
Refunds, the part nobody tests
A customer returns a jacket bought last Tuesday on a card. Three things must happen: the money goes back to the card, the stock returns to the shelf, and the reports stop counting that revenue. Test all three before you go live, including a partial refund on an order that had a split payment. This is where POS setups reveal their gaps, and it always happens on a Saturday.
OpenPOS handles full and partial refunds and exchanges from the register, correcting stock and reporting as it goes.
Frequently asked questions
Can I use my existing online Stripe account in the shop?
Yes, with a Stripe Terminal reader registered to the same account. Online and in-store payments settle together.
Do I have to use a supported terminal?
No. Many shops run a standalone terminal from their bank next to the till and record the sale in the POS as a card payment. You lose the automatic amount transfer, and staff can mistype the amount, but it works and it is common.
Can I take a deposit and the balance later?
Yes, by leaving the order partially paid, or through LayBuy for structured instalments.
Are there transaction fees from the plugin?
None. OpenPOS is a one-time purchase and takes no cut of your sales. You pay your processor’s rates and nothing else.
Take a split payment yourself on the live demo (admin / admin123). Every payment integration above is included in OpenPOS, with no per-transaction charge from us, ever.