Yes, ISVs can add tap-to-pay on Android POS without a separate card reader, by using SUNMI devices that carry a certified contactless payment path inside the hardware. The customer taps a card or phone on the device, and the payment clears through your integrated app. No dongle, no second box on the counter.
This guide is for software vendors and integrators evaluating how to add contactless acceptance to an Android POS build. We cover the two common paths, the certifications that matter, and the SUNMI devices Rosper ships that support tap-to-pay on Android POS.
Rosper is the authorized SUNMI distributor for the United States and Canada. We supply ISVs across 8 North American warehouses with most orders arriving in 2 to 7 business days.
Tap-to-pay on Android POS: key takeaways
- Two integration paths. A dedicated payment device such as CPad Pay handles PCI in hardware; a screen-based approach such as Flex 3 accepts taps directly on the display over software.
- No separate reader needed. Both paths remove the standalone card reader from the counter, so the customer taps the same device your app runs on.
- Certification decides the path. Hardware payment terminals carry a full PCI hardware security boundary; screen-based tap uses an EMVCo PCD L1 certified NFC path with a software audit trail.
- ISVs integrate through SDKs. SUNMI exposes payment SDKs so your Android app drives the tap flow rather than handing off to a separate terminal UI.
What tap-to-pay on Android POS means for an ISV
Tap-to-pay means the customer completes a contactless transaction by tapping a card, phone, or watch on a device. On Android POS, the goal for an ISV is to run that tap through the same device that runs your software, so the merchant carries one device instead of a terminal plus a reader.
There are two ways to deliver this, and the right choice depends on how much of the payment security you want to own versus push into certified hardware. Both keep the merchant on a single device, which is the outcome that makes tap-to-pay on Android POS attractive to ISVs in the first place.
Path 1: dedicated payment device (hardware PCI)
A dedicated payment device puts the card handling inside a PCI-certified secure boundary. The SUNMI CPad Pay line is built this way. It is an 11-inch Android payment tablet with a hardened payment module, so contactless card data never touches your app in the clear.
For ISVs, this path means less compliance scope to carry, because the sensitive part of the flow sits in certified hardware. Your app talks to the payment module through a semi-integrated SDK. The CPad Pay P2 SE and the P3 family devices fit entry-level and higher-throughput deployments respectively.
- PCI hardware boundary. Card data is isolated in a certified secure module, reducing your compliance footprint.
- Semi-integrated SDK. Your app initiates the sale and reads the result; the module handles the card.
- Best for. ISVs that want the smallest possible compliance scope and a purpose-built payment device.
Path 2: tap directly on the screen (software NFC)
The second path accepts the tap on the device screen itself. The SUNMI Flex 3 has NFC under the display with EMVCo PCD L1 certification, so it can act as the contactless acceptance point without an external reader. The customer taps the card or phone on the screen, and your integrated software drives the flow.
This path shifts more of the transaction handling into software, which means a software audit trail rather than a fully isolated hardware boundary. It is a strong fit for self-service, kiosk, and counter setups where a large interactive screen doubles as the tap point.
Comparing the two paths
| Factor | Dedicated device (CPad Pay) | Tap on screen (Flex 3) |
|---|---|---|
| Where card data lives | Isolated PCI hardware module | EMVCo PCD L1 NFC path with software audit trail |
| ISV compliance scope | Smaller, more sits in certified hardware | Larger, more sits in software |
| Form factor | 11 inch payment tablet | 18.5, 22, or 27 inch interactive display |
| Best fit | Mobile and counter payment acceptance | Self-service, kiosk, large-screen counter |
How ISVs typically integrate
The common integration pattern is semi-integrated. Your Android POS app owns the cart, the tax, and the receipt, then calls the payment SDK to run the tap. The SDK returns an approval or decline, and your app closes the sale. This keeps your user experience consistent while the certified payment path handles the card.
- Build the sale in your app. Line items, tax, and total live in your software.
- Call the payment SDK. Your app triggers the contactless prompt on the device.
- Customer taps. The card, phone, or watch taps the device; the certified path clears it.
- Reconcile in your app. The SDK returns the result and your app prints or emails the receipt.
For the developer view, see our SUNMI Android POS SDK integration guide and the CPad Pay ISV integration guide.
What tap-to-pay accepts at the point of sale
When you build tap-to-pay on Android POS, the contactless path accepts more than just a physical card. The same NFC read handles the formats your merchants see every day at the counter.
- Contactless cards. Debit and credit cards with the contactless symbol, tapped on the device.
- Mobile wallets. Phone and watch wallets that emulate a card over NFC.
- Compatible NFC standards. The reader supports ISO/IEC 14443 Type A and B, so it works with the card technologies used across North America.
For the merchant, the experience is the same across all of these: hold near the device, wait for the confirmation, done. For the ISV, one certified read path covers cards and wallets, which keeps tap-to-pay on Android POS simple to support in the field.
A real ISV deployment pattern
Rosper has delivered Android POS hardware to ISVs building vertical software for hospitality, retail, and services. A typical pattern is an ISV that ships its own app to merchants and wants tap-to-pay built in so the merchant never handles a separate reader. The ISV standardizes on CPad Pay for mobile and counter acceptance, and adds Flex 3 where a self-service screen is the tap point.
Because Rosper supplies the hardware and coordinates warranty in North America, the ISV ships one hardware bill of materials to every merchant and has a local contact for support. Details of specific deployments stay confidential to protect the ISV.
This pattern scales well. As the ISV signs new merchants, it orders the same certified devices from one North American source, so every site runs the same tap-to-pay on Android POS flow. That consistency cuts support tickets, because the ISV support team troubleshoots one hardware path rather than a mix of readers and dongles across accounts.
Certifications to confirm before you build
- EMVCo PCD L1. Confirms the contactless reader meets EMVCo Level 1 requirements. The Flex 3 screen NFC carries this certification.
- PCI PTS. Applies to dedicated payment hardware such as the CPad Pay line, where card data sits in a certified secure module.
- Processor certification. Your payment processor and gateway must certify the specific device and SDK path for your region.
You can review SUNMI payment device certifications on the SUNMI site. Rosper helps ISVs confirm the right device and certification path before an order.
Warranty and support for ISV fleets
SUNMI provides the manufacturer warranty on its hardware, with a 3 year term on current-generation devices. Rosper coordinates and assists with warranty and RMA across the US and Canada, which matters when an ISV is managing a fleet across many merchant sites.
Add tap-to-pay to your Android POS build
Choose the dedicated device path for the smallest compliance scope, or the tap-on-screen path when a large interactive display is your tap point. Either way, your merchants get contactless acceptance with no separate card reader. Request a quote from Rosper to spec the right SUNMI devices for your rollout.
SUNMI devices that support tap-to-pay on Android POS
The table below compares common SUNMI payment-class devices an ISV can target for a tap-to-pay build. Confirm the current certified list with Rosper before you commit a design.
| Device | Form factor | Contactless | Best fit |
|---|---|---|---|
| P2 SE | Handheld smart terminal | NFC tap plus screen | Mobile line-busting and table-side |
| P3 | Handheld with card swipe | NFC tap, chip, and swipe | Mixed card acceptance on the floor |
| Countertop terminal | Fixed checkout hardware | NFC tap plus screen | Staffed counters and self-service lanes |
Frequently asked questions
Can an ISV add tap-to-pay on Android POS without a separate card reader?
Yes. Using SUNMI devices with a certified contactless path, such as the CPad Pay payment tablet or the Flex 3 with under-screen NFC, an ISV can accept taps on the same device that runs its app, with no standalone card reader.
What is the difference between a hardware payment device and tap on screen?
A dedicated payment device like CPad Pay keeps card data in an isolated PCI-certified hardware module, reducing the ISV compliance scope. Tap on screen uses an EMVCo PCD L1 certified NFC path in the display with a software audit trail, which shifts more handling into software.
How does an ISV integrate tap-to-pay into its app?
The common pattern is semi-integrated. The ISV app builds the sale, calls the SUNMI payment SDK to run the contactless tap, receives an approval or decline, and closes the sale. The certified payment path handles the card while the app owns the experience.
Which SUNMI devices support tap-to-pay on Android POS?
The CPad Pay line, including the P2 SE and P3 family, supports tap-to-pay through a certified payment module. The Flex 3 supports tap-to-pay directly on the screen through EMVCo PCD L1 certified under-screen NFC.