Every phone your merchants already own, now a certified card terminal.

Three lines, one tap, zero hardware

Tap Terminal is installed as a native module in your existing mobile app, the one your merchants already use for orders, bookings, or dispatch. When it’s time to take payment, your app calls tapTerminal.present(intent) and the SDK takes over: renders the tap UI, drives the NFC radio, runs the EMV kernel, captures PIN if the cardholder-verification method requires it, and returns a signed transaction result.

// React Native, same shape for Swift and Kotlin
import { TapTerminal } from '@tapped/terminal-rn';

const result = await TapTerminal.present({
  amount: 3380,         // minor units
  currency: 'SGD',
  merchantId: 'mer_8Q2',
  reference: 'ord_4019'
});
// → { status: 'approved', tx: 'tx_01HNZ9...', cryptogram: '9F26...' }

That’s the whole integration. Sandbox is a mock kernel; production is the real one. No compile flags to flip.

The specs that matter

• PIN-on-Glass certified to PCI MPoC v1.1 for transactions above the local CVM limit. No separate build.
• Offline queue for up to 2,000 taps, auto-submits when connectivity returns, with scheme-approved force-post handling.
• Device attestation on every tap, SafetyNet / Play Integrity on Android, DeviceCheck on iOS. Rooted and jailbroken devices are rejected at SDK init.
• Theme-aware UI, the tap surface uses your app’s colour tokens by default; opt into a fully-custom presentation for flagship flows.
• Accessibility built in, VoiceOver / TalkBack, dynamic type, high-contrast PIN pad, haptic feedback on success and failure.

Tipping, split checks, refunds, voids

Tap Terminal is more than a card reader replacement. The SDK exposes higher-level primitives for the flows that actually happen at the table, the front desk, and the customer’s driveway.

• Pre-auth + capture. Authorise on check-in, post incidentals to a folio, capture on check-out. Used by every hotel integration.
• Tip prompt. Server-driven, scheme-compliant, rendered pre-auth so the tip is captured inside the cryptogram. No two-step signature workflow.
• Split checks. One tap per payer; Tapped reconciles the group into a single order in the webhook.
• Partial refunds. Refund the original transaction up to 180 days later, routes via the same scheme path, same signed cryptogram chain.
• Void before batch cut-off. Reverse mistakes in the same business day with no scheme dispute ever opening.

Why not use Apple’s Tap to Pay on iPhone or Android’s Tap to Pay?

You can, and in markets where Apple and Google offer their own first-party tap-to-pay, Tap Terminal routes through those APIs transparently. But the first-party options come with limits: Apple’s Tap to Pay is US-and-select-markets only, typically gated to specific PSPs, and forces a Stripe/Adyen-shaped integration on your merchant of record. Tap Terminal works in every APAC market we serve, with or without Apple’s API, and keeps the merchant relationship on your contract.

For the same reason, we don’t depend on any specific phone manufacturer’s SE, the MPoC model allows a secure element in software, audited by PCI, which is how we support mid-range Android devices where hardware SE isn’t available.

Fallback when the phone is uncooperative

Not every phone, and not every card, taps cleanly on the first try. Tap Terminal ships with a graded fallback chain: contactless first, magstripe mode for cards that require it, manual PAN entry for the rare card-not-present fallback, and a QR-to-pay handoff in markets where QR rails are dominant (Thailand PromptPay, Indonesia QRIS, Malaysia DuitNow, Vietnam VietQR). Your merchant never has to apologise to the customer.