- An integrated reader takes the amount from your POS and returns the result, so staff never retype totals.
- Stripe Terminal offers SDKs for iOS, Android, React Native and web, plus a server-driven API for smart readers.
- Square's Mobile Payments SDK and Terminal API connect Square hardware to your own app in a handful of countries.
- A bank terminal can make sense for its rates, but only if the provider offers an integration your developer can use.
- Check country, card brands, hardware, refunds, offline rules and reconciliation before committing.
Which card readers should a custom POS use?
Choose an integrated reader whose provider supports your country, your POS platform and the card brands your customers carry. Stripe Terminal suits most custom builds because of its SDKs and server-driven API; Square suits businesses already on Square in the countries it supports for developers. A bank terminal makes sense only if the provider offers an integration, or if you accept a standalone setup with manual matching.
The reader is chosen together with the POS platform, not after it. Our POS system development team settles both in the first planning session.
What is the difference between integrated and standalone?
- Integrated: the POS sends the amount to the reader, the customer pays, and the POS receives approved or declined with a payment reference. Nothing is retyped, and every payment is linked to its order.
- Standalone: staff type the amount into a separate terminal and mark the order as paid. It is quick to start, but typing errors, missed payments and end-of-day matching become your problem.
In both cases the card data should go from the reader to the payment provider, not through your software. Our guide to PCI DSS for a custom POS explains why that matters.
How does Stripe Terminal work with a custom POS?
Stripe Terminal offers SDKs for iOS, Android, JavaScript and React Native, plus an API-based integration, per the Stripe Terminal documentation. Its integration guide sets out the trade-offs (Stripe: design an integration):
- Server-driven integration: your POS talks to your server, your server calls Stripe, and Stripe controls the reader. The POS can run on any device, but this route works only with smart readers and does not support collecting payments offline.
- Native SDKs for iOS, Android and React Native work with smart readers, Bluetooth mobile readers and Tap to Pay.
- The JavaScript SDK is for web-based POS apps with smart readers only.
Smart readers connect over Wi-Fi or Ethernet and can show the cart and collect tips on screen; some can even run your own Android POS app on the reader. Mobile readers pair with a phone or tablet over Bluetooth. Terminal is generally available in 24 countries, including the United States, Canada, the United Kingdom, Australia and much of Europe, with more in preview, according to Stripe's Terminal availability list.
How does Square fit a custom POS?
Square offers two routes. The Mobile Payments SDK embeds Square's payment flow in your own iOS or Android app and works with any version of Square Reader or Square Stand. It replaced the older Reader SDK and is available for accounts based in the United States, Canada, the United Kingdom and Australia, per Square's Mobile Payments SDK docs.
The Terminal API lets your POS send a checkout to a Square Terminal device, which then takes the payment, as described in the Terminal API overview. This suits a POS that runs on a computer or browser at the counter, with the Square Terminal beside it.
Square is a natural choice if the business already uses Square for payments and payouts; check that your country and setup are covered before designing around it.
When does your bank's terminal make sense?
Banks and local payment companies sometimes offer better rates or support for local card schemes. The question is integration. Ask for:
- A documented API or SDK for your POS platform, and a test environment with test cards.
- How the result comes back: approved or declined, a reference, and the card brand.
- Refunds, cancellations and tips through the same integration.
- Settlement reports your accounts team can match against POS sales.
If the answers are vague, plan for a standalone setup and budget the manual matching, or choose a provider with a developer platform.
How do the options compare?
| Stripe Terminal | Square | Bank terminal | |
|---|---|---|---|
| Integration | Native SDKs, JavaScript SDK, server-driven API | Mobile Payments SDK, Terminal API | Depends on the provider |
| POS platform | iOS, Android, React Native, web with smart readers | iOS and Android apps, or any POS through Square Terminal | Ask the provider |
| Tap to Pay on phones | Yes, iPhone and Android | Yes, separate guides | Varies |
| Best fit | Most custom builds in supported countries | Businesses already on Square | Local rates or schemes, if an integration exists |
What about Tap to Pay on a phone?
Tap to Pay lets a compatible iPhone or Android phone accept contactless cards and wallets without extra hardware. It suits staff who move around: table service, deliveries, events and queue busting. It does not replace a counter reader for chip and PIN, and it ties up a staff phone, so most shops use it alongside readers.
What if the internet goes down?
Some providers can store card payments and forward them when the connection returns, but the business carries the risk of declines, and providers set limits. Stripe describes this for supported readers (Stripe: offline payments), and Square limits offline payments to recent reader models. Our guide on planning offline mode for a POS app covers the rules to set.
What should you check before committing?
- Is the provider available in every country you trade in, and does it accept your customers' local card brands?
- Can you buy and replace readers easily where your branches are?
- How do refunds, partial refunds and tips work through the API?
- How do payouts and fees appear, so finance can match them to sales?
- What does the test environment offer: simulated readers and test cards?
We build the POS screens, the payment integration and the reporting behind them through our custom software development service.
Frequently asked questions
Can we keep our current bank terminal and still build a custom POS?
Often yes, as a standalone setup: staff key the amount into the terminal and mark the order as paid in the POS. It works, but it adds typing errors and manual end-of-day matching. Ask your bank or terminal provider whether they offer an integration API or SDK; if they do, the POS can send the amount directly.
Do card readers work with a web-based POS?
Some do. Stripe offers a JavaScript SDK for web-based POS apps, but only with its smart readers, and its server-driven integration lets a POS on any device control a smart reader through your server. Bluetooth readers need a native iOS or Android app. Decide the POS platform and the reader together.
Is Tap to Pay on a phone enough for a shop?
For mobile staff, pop-up stalls, deliveries and queue busting, often yes. For a busy counter, a dedicated reader is usually more practical: it has its own screen for the customer, accepts chip and PIN, and does not tie up a staff phone. Many businesses use both.
Who handles PCI compliance with an integrated reader?
With certified readers and the provider’s SDK, card data goes from the reader to the provider and never through your POS, which keeps most card data out of your systems. You still have responsibilities, such as never keying card numbers into your own screens. Our guide to PCI DSS for a custom POS explains the split.
How do refunds work with an integrated reader?
Refunds are made through the provider’s API, linked to the original payment, so the POS can show which order was refunded and by whom. Plan who is allowed to refund, add a reason field, and record it in the audit log.
Last updated