CPad Pay ISV integration ships in 2 to 4 weeks for most 2026 builds when the ISV partner starts from the SUNMI Unified SDK and the semi-integrated payment pattern that Rosper distributes to its US-domestic partner roster. The integration path keeps the ISV out of PCI DSS scope for the payment kernel and gives the merchant a single PCI PTS 6.x certified hardware device. The 8-step build path below is the sequence Rosper walks every ISV through.

CPad Pay ISV integration: why semi-integrated, not full integration

Two integration patterns exist. Full integration means the ISV writes the EMV kernel and the cryptographic primitives. That puts the entire ISV stack into PCI DSS scope, requires QSA audit, and adds 6 to 9 months to the timeline. Semi-integrated means the ISV calls a SUNMI Unified SDK deep-link, the SUNMI PCI PTS 6.x kernel handles the entire cryptographic transaction, and the SDK returns the result to the ISV app. The kernel and PCI scope live on the device. The ISV app stays in PCI DSS Self-Assessment Questionnaire scope at most. The PCI Security Standards Council documents the difference under the PA-DSS and P2PE programs.

For 2026 ISVs targeting QSR, retail, salon, and hospitality merchants in the US, semi-integrated is the right pattern. The ISV ships faster, the merchant gets a PCI-certified device, and the audit surface stays small.

Step 1: Get the SUNMI Unified SDK from Rosper

Rosper’s ISV partner program ships the SUNMI Unified SDK to qualified partners with a signed Mutual NDA. The SDK includes the deep-link API reference, the payment kernel response schema, the on-screen tip and signature UI components, and the sandbox merchant credentials for the BIN sponsor that Rosper has pre-arranged. Most ISVs receive the SDK within 5 business days of NDA execution. The SUNMI Developer Center hosts the public API documentation for reference.

Step 2: Provision a test merchant on the BIN sponsor

Every CPad Pay deployment in the US requires a merchant services BIN sponsor (the acquiring bank that holds the EMV certification with Visa, Mastercard, Discover, and American Express). Rosper pre-arranges three BIN sponsor relationships and provisions test merchants for ISVs in sandbox. The ISV receives a test merchant ID, a test terminal ID, and a set of test card PANs that hit known authorization paths. This is the merchant against which the ISV will run the EMV test matrix in Step 7.

Step 3: Wire the deep-link transaction request

The ISV POS UI builds a transaction request as a JSON object: amount, currency, transaction type (sale, refund, void, pre-auth, capture), tip-prompt flag, signature-prompt flag, receipt-routing preference. The request is passed to the SUNMI Unified SDK as a deep-link Intent on Android. The SDK validates the payload and hands off to the on-device payment kernel.

• Request payload: JSON with amount in minor units (cents), 3-letter currency code, transaction type enum
• Deep-link: Android Intent with action SUNMI_PAY_TRANSACTION and the JSON payload as an extra string
• Response: same Intent contract returns a result JSON with transaction outcome, masked PAN, last 4, EMV TAGs
• Timeout: configurable per transaction, default 60 seconds for EMV contact, 15 seconds for contactless

Step 4: Handle the payment kernel response

The kernel returns one of six outcomes: approved, declined, cancelled (operator), cancelled (timeout), referral (call issuer), error (hardware). The ISV app handles each path. Approved triggers receipt rendering and order completion. Declined triggers the retry prompt with a 3-retry cap to avoid card-not-present fraud patterns. Referral triggers a manual auth code entry flow. Error triggers a kernel diagnostic and a Rosper support touch.

Step 5: Render the tip and signature on-screen

CPad Pay’s 11-inch screen and free-flip hinge make the tip-prompt UI clean. The SUNMI Unified SDK ships pre-built tip components (preset percent, custom amount, no tip). The ISV can use the bundled components or render its own UI and pass the final tip amount in the response. Signature capture is on-screen for tickets above the BIN sponsor signature CVM floor. The signature is captured as a PNG and stored against the merchant transaction record.

Step 6: Manage receipts and routing

Three routing options exist for receipts: email (ISV app collects email and sends via its own ESP), SMS (ISV app collects phone and sends via its own SMS gateway), paper (snap-on 80mm printer prints on CPad Pay back-of-device). The ISV controls the receipt content and the routing logic. SUNMI returns the transaction data; the ISV formats and routes.

Step 7: Test EMV contact, contactless, magstripe, QR

Before BIN certification, the ISV runs the full EMV test matrix against the sandbox merchant. Typical matrix:

1. EMV contact: insert chip, sign, approve. Validate kernel response includes EMV TAGs (5F2A currency, 9F26 application cryptogram, 9F27 cryptogram information data).
2. EMV contactless: tap NFC card. Validate the contactless kernel completes in under 500 milliseconds.
3. Magstripe fallback: swipe a magstripe-only card. Validate the fallback path triggers only when chip read fails 3 times.
4. QR code: render a domestic QR scheme the BIN sponsor acquires. Validate the QR-to-acquirer hop completes.
5. Refund: refund a settled transaction. Validate the refund response carries the original auth code.
6. Void: void an unsettled transaction. Validate the void response and the daily batch shows the voided ticket as nil.
7. Pre-auth and capture: hotel and rental flow. Validate the pre-auth holds funds and the capture finalizes the ticket.

Step 8: Certify on the BIN sponsor staging

The BIN sponsor runs a final certification pass against the ISV build. The certification typically takes 5 to 10 business days and covers EMV TAGs, receipt formatting, error handling, void and refund flows, and PCI DSS Self-Assessment Questionnaire scope verification. Once certified, the BIN sponsor lists the ISV as a CPad Pay-compatible solution. Rosper coordinates the ISO and acquirer relationships that smooth the certification path.

CPad Pay ISV integration: production rollout and ongoing maintenance

After certification, the ISV ships its first merchant. Rosper coordinates hardware delivery (3 to 5 business days from US warehouses), merchant onboarding with the BIN sponsor, and the SUNMI MDM Partner Platform enrollment so the ISV manages the device fleet from one console. For 2026, EMV kernel updates push via SUNMI OTA roughly twice per year; the ISV does not own kernel maintenance. See the CPad Pay product page for the current Gen-3 SKU list.

CPad Pay ISV integration timeline and cost data

Time to first live transaction

ISV teams with one Android engineer and one QA engineer hit a first sandbox transaction in 7 to 10 business days from SDK delivery. The breakdown: 1 day for SDK install and Android Studio project setup, 2 to 3 days to wire the deep-link transaction request and parse the response, 1 day for tip and signature UI, 1 day for receipt rendering, and 2 to 4 days for end-to-end QA across EMV contact, contactless, magstripe, and QR. Production certification with the BIN sponsor adds 12 to 21 calendar days on top, depending on the acquirer’s queue depth and how many transaction types the ISV needs certified.

Integration cost compared with full integration

Semi-integrated payment via deep-link costs roughly $18,000 to $32,000 in engineering time at typical US ISV rates (90 to 140 hours at $200 per hour). Full integration with the payment kernel on the ISV side runs $180,000 to $340,000 because the ISV must achieve PCI DSS Level 1 certification, maintain EMV kernel updates, and carry the audit overhead for 12 to 18 months per cycle. Semi-integrated keeps PCI scope at the device level, where SUNMI holds the PCI PTS 6.x certification, and the ISV ships SAQ A or SAQ A-EP scope – the lowest two PCI audit tiers.

Throughput and reliability data from production ISVs

ISVs running CPad Pay in production across 200 to 2,000 merchants report transaction round-trip time of 1.8 to 2.4 seconds for contactless, 3.1 to 4.0 seconds for chip-and-PIN, and 0.9 to 1.3 seconds for magstripe. Failure rates from kernel-side errors run under 0.04%, mostly tied to network drops at the acquirer rather than device-side issues. The deep-link return-to-app handoff is below 600 ms on 95% of transactions, fast enough that the cashier UI does not need a spinner overlay.

Ongoing maintenance overhead

EMV kernel updates run on SUNMI’s OTA cycle, not on the ISV. A typical year has 2 to 3 kernel updates, each pushed silently to deployed CPad Pay devices through the SUNMI Partner Platform. ISV-side work to keep the integration current is essentially zero unless the ISV wants to add a new transaction type (refund-by-original-tender, partial-auth, multi-tender) which adds 8 to 16 hours per type. Compare that with the 40 to 60 hours per kernel update an ISV running its own EMV kernel typically logs.

ISV resources and ongoing support

SDK access and developer-relations support

The SUNMI Unified Payment SDK is gated behind a partner-developer account, provisioned by Rosper for ISVs working on a CPad Pay integration. Provisioning takes 1 to 2 business days from the signed NDA. The SDK ships with Android Studio sample projects covering deep-link transaction request, tip and signature UI, receipt rendering, EMV kernel response parsing, and refund-by-original-tender. Sample apps build clean on Android Studio Hedgehog and later. Rosper’s ISV-relations engineer is on call for the first 30 days of any new integration, with average response time under 4 business hours on weekdays for technical questions. The same engineer coordinates BIN sponsor introductions when the ISV needs a payment processor that supports CPad Pay – currently 6 US acquirers and 3 Canadian acquirers are CPad-certified.

ISV developer community and code samples

The SUNMI Developer Hub hosts working code samples in Kotlin and Java covering deep-link transaction request, EMV response parsing, refund-by-original-tender, partial-auth flow, and signature-on-screen capture. Sample apps build clean against Android Gradle Plugin 8.x and target Android 12 through Android 14. The community forum carries about 1,400 active threads as of mid-2026 with average first-response time under 18 hours from SUNMI engineering. ISVs running production CPad Pay integrations have direct access to the SUNMI engineering Slack channel through Rosper’s ISV-relations contact.

Frequently Asked Questions

Does the ISV need PCI DSS Level 1 certification?

No. Semi-integrated payment keeps the payment kernel and the cryptographic primitives on the CPad Pay hardware. The ISV typically falls into PCI DSS Self-Assessment Questionnaire scope, not Level 1 audit scope. Confirm with your QSA against the specific data flows your POS handles.

How long does the full integration take?

Most ISVs complete CPad Pay integration in 2 to 4 weeks. Week 1 is SDK install and first sandbox transaction. Week 2 is deep-link wiring and tip and signature flow. Week 3 is the full EMV test matrix. Week 4 is BIN sponsor staging certification.

Can the ISV use its own BIN sponsor?

Yes. Rosper pre-arranges 3 BIN sponsor relationships for fast onboarding, but ISVs with existing BIN sponsor relationships use those directly. The SUNMI Unified SDK is BIN-agnostic; certification happens against whichever BIN sponsor the ISV picks.

How does the ISV handle EMV kernel updates?

SUNMI pushes EMV kernel updates via OTA roughly twice per year. The ISV does not own kernel maintenance. The SDK API contract is versioned, so kernel updates rarely require ISV code changes.

Does the ISV need a separate Android Studio project for CPad Pay?

No. The ISV’s existing Android POS app installs on CPad Pay. The SUNMI Unified SDK is added as a Gradle dependency. The build target is standard Android API level 30 or higher for Gen-3 CPad Pay.