How to Accept Card Payments in a Custom POS App
A card form is not a card terminal. Here are the four real ways to accept card payments in a custom or AI-built POS app, what Apple, Google and your payment provider require for each, and how long it takes.
Mathias NielsenCEO, Final POS
To accept card payments in a custom POS app, you go through a payment service provider (PSP) and one of four routes: a certified card reader, Tap to Pay on iPhone, Tap to Pay on Android, or a cloud-connected smart terminal. Your app never reads a card number. It sends an amount to certified hardware or software, and gets back approved or declined. Each route has its own requirements from Apple, Google or your provider, and that paperwork, not the code, is what takes the time.
This guide lays out every route step by step, with the real requirements and nothing inflated. We run payments for our own POS, Final, so we have been through each of these.
Why can't you just add a card form to your POS?
Because a card form makes the sale card-not-present, and a store counter needs card-present. When a customer types a card number into a web form, the payment is treated like an online order: higher fees, more fraud exposure and more of the dispute risk on you. When a certified device reads the card or phone, the payment is card-present, which is cheaper and safer for everyone.
Card-present acceptance requires certified hardware or software. That is why every route below runs through a PSP's in-person product rather than your own code. The fee difference is explained in card present vs card not present.
Route 1: How do you use a card reader with your own app?
Pick a PSP with an in-person SDK, buy one of its certified readers, and pair it from your app. Stripe Terminal, Adyen and others work this way.
Open an account with the PSP and enable its in-person product.
Integrate its iOS, Android or React Native SDK.
Order certified readers and register them to your account.
Discover and connect readers from your app, then collect payments through the SDK.
Plan for reader firmware updates, which the PSP pushes.
You cannot connect an arbitrary reader: only readers certified with your provider can process cards, because certification covers the exact reader, software and processor combination. More in card readers for custom POS apps and EMV certification for a POS.
Route 2: What does Tap to Pay on iPhone require?
Tap to Pay on iPhone turns the phone into the reader. Apple's own steps are: work with a supported PSP, request the Tap to Pay on iPhone entitlement, integrate the ProximityReader API or your PSP's SDK, follow Apple's Human Interface Guidelines, and submit your app for review (Apple's Tap to Pay overview). Apple states that the PSP is responsible for the certifications that let merchants accept payments.
In practice that means:
An organisation developer account. The entitlement request must come from the Account Holder of an organisation account, and enrolling as an organisation needs a D-U-N-S number. See D-U-N-S numbers and Apple developer accounts.
The request form. Name your PSP and the regions you will operate in.
A development entitlement. Apple grants one for building and testing on your own devices.
Apple's UX requirements. Apple sends its requirements and marketing guidelines with the entitlement, covering button labels, entry points and onboarding.
A distribution entitlement. You reply to Apple's email and re-request for distribution. TestFlight and the App Store need this one.
App Review. Your app ships once it passes.
It runs on iPhone XS or later and not on iPad. The full walkthrough is in how to get the Tap to Pay on iPhone entitlement, with review tips in passing App Review with a Tap to Pay app and alternatives in why Tap to Pay does not work on iPad.
Route 3: How does Tap to Pay on Android differ?
There is no Apple-style entitlement on Android, but the PSP's SDK enforces its own checks. Typical requirements:
An Android device with built-in NFC running Android 11 or later
A Google-certified device that passes integrity attestation
A non-debuggable build: PSP SDKs refuse to take real taps in debug mode, so you test with a simulated reader
Location and other permissions the SDK asks for
Android tablets can work if they meet the provider's requirements. Details in Tap to Pay on Android in a custom app.
Route 4: Can a browser-based POS take cards?
Yes, through a cloud-connected smart terminal. Your server tells the PSP's API to send a payment to a specific terminal on the counter; the terminal handles the card and reports the result back to your server. This is the only in-person route a web POS can use, because a web page cannot read a tapped card and Safari cannot reach Bluetooth readers.
It suits counter-service stores with a fixed terminal. It adds a network dependency, so plan what happens when the store's connection drops.
How do you choose a payment provider for a custom POS?
Start with the countries you sell in, then onboarding and hardware:
| Question | Why it matters |
|---|---|
| Is the provider live in your countries? | Tap to Pay and readers roll out country by country |
| Is onboarding self-serve? | Stripe is self-serve; Adyen focuses on larger businesses and reviews applicants more selectively |
| Which SDKs does it offer? | iOS, Android, React Native and server-driven terminals differ by provider |
| Which readers are certified? | Only certified readers work |
| Does it support offline payments? | Store-and-forward is provider-specific and shifts decline risk to you |
| Are you onboarding other merchants? | If so, you are a platform and may need payfac arrangements |
Our side-by-side is Stripe Terminal vs Adyen for a custom POS app. If you plan to take payments on behalf of other businesses, read become a payment facilitator or use a platform first; for a single store you are simply a merchant.
What compliance do you inherit, and what do you keep?
Using a PSP's certified SDK or reader means card data never touches your code, which keeps your PCI scope small. The PSP carries the payment certifications. You still keep:
A PCI self-assessment questionnaire with your processor
Access control, logging and updates on the devices running your POS
Correct receipts, refunds and tax reversal
Apple's and your PSP's display and marketing rules for Tap to Pay
If you are building the rest of the POS too, our pillar on how to build your own POS system with AI covers PCI, tax and deployment, and POS hardware for custom apps covers printers and drawers.
How long does it take to accept your first card payment?
| Step | Typical time |
|---|---|
| Organisation Apple account with D-U-N-S (for Tap to Pay on iPhone) | Days to a few weeks |
| PSP account and in-person product enabled | Same day to several weeks, depending on provider |
| SDK integration and test payments | 1 to 3 weeks |
| Tap to Pay development, then distribution entitlement | Weeks |
| App Review | Days, longer if rejected |
Can you take cards on day one instead?
Yes, by building your checkout on a platform that already holds the approvals. That is Final. Your AI builds the checkout in Flow Studio, and when it asks for a card payment, Final Pay handles the reader or Tap to Pay:
Readers and Tap to Pay already approved. Final Pay accepts card, contactless and Tap to Pay on supported devices. See how to take a Tap to Pay payment and how to take a payment at checkout.
Your own AI builds it. Connect Claude, Cursor or any MCP client through Final's MCP server.
Pricing in one line. No subscription. Cash is $0. Card is 2.49% + $0.10 in the US and worldwide, 1.99% in Canada and 0.99% in Europe.
The honest trade-off: you process through Final Pay rather than choosing your own provider, and availability varies by country and device, listed in where Final Pay is available. If payments are your product, build the integration yourself using the routes above. If payments are how you get paid, the approvals are already done.
Frequently asked questions
How do I accept card payments in my own POS app?
Through a payment service provider's in-person SDK: a certified card reader, a cloud-connected smart terminal, or Tap to Pay on a phone. Your app never handles raw card data; it sends an amount and receives a result.
Can a web-based POS take card payments in person?
Yes, by driving a cloud-connected smart terminal through the payment provider's API. A web page cannot read a tapped card on its own.
What does Tap to Pay on iPhone require?
A supported payment provider, the Tap to Pay entitlement requested by the Account Holder of an organisation Apple developer account, a development entitlement and then a distribution entitlement after Apple's UX review, and App Review. It works on iPhone XS or later.
Does Tap to Pay work on iPad?
No. Tap to Pay on iPhone is iPhone only. iPad POS apps take cards with a certified Bluetooth reader or a smart terminal.
Which payment provider should a custom POS use?
Stripe Terminal is self-serve and quick to start for small teams. Adyen suits larger businesses and is more selective about onboarding. Your countries, hardware and volume decide the rest.
What does Final charge for card payments?
No subscription. Cash is $0, and card is 2.49% + $0.10 in the US and worldwide, 1.99% in Canada and 0.99% in Europe.