Table of contents
If you are working with the SUNMI semi-integrated payment SDK for a US or Canadian deployment, this guide is written for you. If you are an ISV, a POS software vendor, or an in-house engineering team shipping a retail or restaurant POS to the US or Canadian market, sooner or later you have to answer the same question: how does your POS app talk to the payment terminal without becoming PCI-scope yourself? On a SUNMI device that question has four good answers, not one. This guide walks through the four semi-integrated modes SUNMI supports, when each one makes sense, and how they land in a North American deployment where EMV certification, PCI PTS 6.X, and a specific acquirer relationship all matter.
Rosper is the authorized SUNMI distributor for the United States and Canada. We stock P2, P2 Pro, P2 Mini, P2 Smartpad, and the CPad Pay across our Maryland and Los Angeles warehouses, and we work with ISVs who need to pick the right integration mode before they build. If this guide raises a specific integration question for your stack, there is a direct contact path at the end.
What you need to know about SUNMI semi-integrated payment SDK
What “semi-integrated” actually means
In a fully integrated model, your POS app handles the card data end to end. That puts you squarely into PCI-DSS scope. In the SUNMI semi-integrated payment SDK model, your POS app only sends a transaction request to a payment component, and the card data never touches your app. The payment component runs on a PCI-PTS-approved device, talks to the acquirer, and returns a sanitized result, such as “approved, last 4 digits, auth code, receipt data.” Your scope shrinks from full PCI-DSS to a much narrower set of responsibilities.
On a SUNMI all-in-one device like the P2 Pro, P2 Mini, or CPad Pay, “the payment component” is a SUNMI-provided payment app or service that runs on the same device as your POS app. Your POS app calls it, it takes over the screen and PIN pad, processes the transaction with the SUNMI EMV kernel and the acquirer’s kernel configuration, then returns control and a result. The four SUNMI modes below are four different ways your POS app can make that call.
Mode 1 – Android Service SDK (the most common choice)
In Android Service mode, your POS app binds to a SUNMI-provided Android Service on the same device using the Android bindService mechanism. You ship the SUNMI payment service as an AIDL contract, call a method like startPay(requestJson, callback), and receive the result via the callback you registered.
When it fits:
– Both your POS app and the SUNMI payment app live on the same SUNMI all-in-one device (P2 Pro, P2 Mini, P2 Smartpad, CPad Pay).
– You want the tightest, lowest-latency coupling.
– You want AIDL type safety and callbacks instead of wire-format parsing.
– You are comfortable with Android-first development.
Trade-offs: The SDK is Android-only, so a cross-platform POS codebase (for example, a single React Native app that also targets iPads) needs a separate integration path on non-Android devices. If your POS is already Android-native, the Service SDK is the cleanest option.
North America notes: Most ISVs targeting full-service restaurants and retail on SUNMI P2 Pro or CPad Pay in the US and Canada end up here. The Service SDK exposes a transaction workflow that lines up with how US/Canada acquirers expect EMV Contact L2, EMV Contactless (Visa, MC, Amex, Discover), and PIN entry to be orchestrated on a PCI PTS 6.X device.
Mode 2 – TCP/IP semi-integrated
In the SUNMI semi-integrated payment SDK TCP/IP mode, your POS runs on a separate box (for example, a Windows ECR or a Linux-based POS appliance) and sends transaction requests to the SUNMI payment device over a TCP socket on the local network. The SUNMI payment app on the device listens on a TCP port, parses the request, runs the transaction, and returns a structured response.
When it fits:
– Your POS app is not on the SUNMI device. You have a classic split architecture: ECR on one machine, payment terminal on another.
– You want the same wire protocol across multiple payment brands, so you can swap vendors without rewriting your POS.
– You run on a closed store LAN and you already have a wired or Wi-Fi network.
Trade-offs: You have to think about network reliability and latency. Retries, timeouts, and idempotency keys are your responsibility. On a flaky Wi-Fi network, this mode is noticeably less predictable than the Android Service SDK.
North America notes: This is the common choice for US retail operators migrating from a legacy Ingenico or Verifone serial ECR integration. The SUNMI TCP/IP protocol is documented, the message format is predictable, and porting from a legacy POS is often a matter of swapping the device driver, not the whole integration.
Mode 3 – USB semi-integrated
In USB mode, your POS is connected to the SUNMI payment device by USB, typically USB-CDC or a similar serial-over-USB profile. The POS acts as USB host, sends request frames, and reads response frames. This is the modern replacement for the old RS-232 serial ECR integration.
When it fits:
– You need a physically wired link because the store has no usable LAN segment for payment traffic.
– You are replacing a legacy serial ECR integration and want to preserve a one-to-one wired link between POS and terminal.
– You want to eliminate network-layer failure modes entirely.
Trade-offs: You lose the flexibility of being anywhere on the LAN. Cable length is limited. Adding a second register means a second cable run. Shared-terminal patterns (one payment device used by two POS lanes) become harder.
North America notes: USB mode is most common in pharmacy, grocery, and fuel-adjacent use cases where compliance teams push back on any “payment traffic on the store Wi-Fi” pattern. SUNMI USB semi-integrated mode is a clean upgrade path from a legacy serial Verifone or Ingenico pinpad.
Mode 4 – POSTMAN semi-integrated
POSTMAN mode is SUNMI’s way of saying “we expose an HTTP or HTTPS-style request/response surface on the device, and you can drive it from a test tool, a web app, or any language that speaks HTTP.” The name comes from the fact that you can literally use the Postman API client to hit the endpoint and run a transaction during development.
When it fits:
– Your POS is a web app running in a browser on the store floor, and you cannot install a native driver.
– You want to prototype and QA transactions before writing any production integration code.
– You are building a language-agnostic, REST-style integration so that Node, Python, .NET, and Java POS clients can all hit the same interface.
Trade-offs: HTTP has more overhead than TCP or USB, and you have to think through localhost vs LAN endpoints, TLS, and auth. Not every acquirer or processor is happy with a browser-driven flow, so check with your payment partner before committing.
North America notes: This mode is the right answer for a specific buyer: a browser-based POS, often SaaS, running on the same Android device. It is also the right answer during integration testing: you can replay captured requests, diff responses, and build automated regression suites without a physical card.
How the four modes compare at a glance
| Mode | Physical link | Wire protocol | Best when your POS is | Typical North America buyer |
|---|---|---|---|---|
| Android Service SDK | Same device | AIDL / Android IPC | Android, same device | Full-service restaurants on P2 Pro or CPad Pay |
| TCP/IP | LAN (Wi-Fi or Ethernet) | SUNMI TCP message | Not on the device, on a separate ECR | US retail migrating from Ingenico/Verifone serial |
| USB | Direct USB cable | Serial-over-USB frames | Not on the device, wired requirement | Pharmacy, grocery, compliance-sensitive ECR |
| POSTMAN | LAN, often localhost | HTTP / HTTPS | Browser app or language-agnostic | SaaS browser POS, rapid prototyping |
The transaction workflow underneath all four modes
Regardless of which mode you pick, the transaction workflow on a SUNMI PCI-PTS-certified device follows the same outline. Your POS sends a request that names the transaction type (sale, refund, void, auth-only), the amount, currency, and any optional fields (order reference, tip prompt flag, tender type hint). The SUNMI payment app takes over the screen, prompts for card, runs the EMV kernel flow (Contact L2 or Contactless), handles PIN entry on the PIN pad, talks to the acquirer, and returns a structured response with an approval or decline, the last 4 digits, the auth code, EMV tag data for the receipt, and any processor-specific reference.
If your POS needs to print a merchant receipt, the response contains what you need. If you want the SUNMI payment app to print the receipt itself on the device’s built-in thermal printer, you can set a flag in the request. This is where the integration modes converge: they are four ways to carry the same transaction contract across four different physical and logical boundaries.
EMV, PCI PTS 6.X, and what the SUNMI device covers
A common misconception: “the device is PCI PTS 6.X certified, so we are done with compliance.” In practice, the device certification covers the hardware, the secure processor, the EMV L1 and L2 kernels, and the contactless kernels (Visa PayWave, MasterCard PayPass, Amex ExpressPay, Discover DPAS, and in some SKUs UnionPay QuickPass and JCB Contactless). What it does not cover is your acquirer’s own processor certification, your end-to-end encryption path, and your POS app’s handling of transaction metadata.
On SUNMI P2-series devices, the EMV kernel version the device ships with is visible in the payment service settings, and SUNMI exposes an SDK API to read system parameters including EMV kernel version. If an acquirer asks “which EMV kernel is on the device,” that is the source of truth. The latest kernel on shipping P2 Pro and CPad Pay devices is EMV 100, which replaces the older EMV 001 on early P2-series units.
For LOAs (Letter of Authorization), SUNMI maintains a current package covering EMV L1 Contact, EMV L2 Contact, EMV L1 Contactless, and the card-brand contactless kernels, plus Flash, PCI-PED, and TQM, for the P2, P2 Pro, P2 Mini, and P2 Smartpad. Rosper can send the current LOA package on request for procurement. For a deeper breakdown of what PCI PTS 6.X covers and what it does not, see PCI PTS 6.X on SUNMI payment devices.
Development and QA workflow in practice
A typical SUNMI semi-integrated integration in the US or Canada unfolds like this. An ISV picks the mode that matches their POS architecture. They receive a developer P2 Pro or P2 Mini unit from Rosper, along with the SDK documentation and a link to the payment test app. They run transactions first in POSTMAN mode to validate the request and response shapes. They then write their production integration against the chosen mode (usually Android Service SDK if the POS is on-device, TCP/IP if the POS is a separate machine). They line up an acquirer for end-to-end testing against a test BIN range. When the acquirer’s test phase passes, they move to certification, and finally into production. Rosper can coordinate the development unit, the SUNMI technical contact, and introductions to acquiring partners that already support SUNMI P2-series devices. For fleet management after deployment, see the SUNMI MDM Partner Portal guide.
Frequently asked questions
Q: Do I have to pick one mode and stick with it?
Your POS app usually commits to one mode per deployment, but the SUNMI device supports all four modes concurrently. You can integrate with Android Service in production and still use POSTMAN for development and QA.
Q: Is the SUNMI payment SDK free?
The SDK and documentation are available to registered ISV partners at no cost. Commercial terms are tied to the specific acquirer and to device procurement through Rosper, not to the SDK itself.
Q: Can I integrate with the same SDK on a P2 Mini and a CPad Pay?
Yes. The SDK surface is the same across the P2-series payment devices and CPad Pay. Some fields differ when the CPad Pay is paired with a secondary Android POS head unit like the T3 Pro, but the core transaction contract is shared.
Q: Which mode does Rosper recommend for a new SUNMI ISV in the US or Canada?
If your POS app is Android-native and runs on the payment device itself, the Android Service SDK is the default recommendation. If your POS is a separate Windows or Linux box, TCP/IP is the default. If it is a browser app, POSTMAN. USB is the exception case for compliance-sensitive deployments.
Q: How does this interact with PCI PTS 6.X?
The device and its payment app are PCI PTS 6.X certified. The semi-integrated architecture keeps your POS app out of PCI-PTS scope. You still need to handle PCI-DSS responsibilities at the network and data-handling layer for any payment data you receive back (masked PAN, auth code, EMV tag data).
Where to go next
If you are evaluating SUNMI for a new POS integration in the US or Canada, Rosper can send a developer unit, connect you to the SUNMI semi-integrated documentation set, and introduce you to acquiring partners already running SUNMI P2-series devices in production. Start with the SUNMI P2 Pro Family and the CPad Pay product pages, then contact [email protected] or visit our contact page.