Device Security
Learn how Tapaya Accept SDK secures transactions with device integrity checks and data protection, and how to integrate and deploy it in a production-ready configuration.
Tapaya Accept SDK transforms consumer off-the-shelf (COTS) devices into secure payment terminals. Because these devices are not dedicated payment hardware, the SDK implements rigorous security measures to mitigate threats and ensure compliance with PCI standards.
Device Attestation
To ensure the payment environment is secure, the SDK performs continuous health checks on the host device. If any security violation is detected, the SDK will refuse to initialize or process transactions.
Root and Jailbreak Detection
The SDK monitors the environment for indicators of privilege escalation. This includes detecting root binaries or privilege management frameworks such as Magisk or SuperSU. It also verifies unauthorized read or write access to protected system directories. In addition, it identifies non-standard operating system builds, including custom ROMs or modified kernel signatures.
Debugging Detection
To prevent reverse engineering and unauthorized testing, the SDK detects whether a debugger is attached to the application and verifies that it is running on a physical device. Execution is restricted in emulator or virtual environments.
Google Play Integrity API
On Android, the SDK leverages the Play Integrity API to validate that the device binary is recognized by Google and hasn't been tampered with.
Application Security
Code Obfuscation
The Tapaya Accept SDK uses advanced obfuscation techniques to reduce the risk of reverse engineering. Code symbols are renamed to non-descriptive identifiers, program logic is deliberately obscured, and sensitive strings or embedded keys are encrypted.
Anti-Tampering
The SDK verifies its own integrity at runtime. It checks the digital signature of the application and the SDK libraries. If the APK has been modified or repackaged by a third party, the SDK will fail to start.
Data Protection
End-to-End Encryption (E2EE)
Card data is encrypted as soon as it is read from the NFC controller. Strong industry-standard encryption is used, and decryption keys are stored only within secure HSMs. The mobile device never has access to raw card data.
Secure Input
For PIN-based transactions, the SDK ensures secure entry. The PIN screen is protected from overlay attacks, the keypad layout is randomized, and all touch input is validated to come from the physical device.
Environment Monitoring
Screen Recording Prevention
To protect sensitive data, the SDK blocks screenshots, screen recordings, and screen sharing by enforcing secure display controls on the device.
Accessibility Services
Malicious apps often abuse Accessibility Services to read screen content or inject inputs. The SDK detects active accessibility services. While it allows standard services for visually impaired users (like TalkBack), it may block unknown or suspicious services during the payment flow.
Attestation and Monitoring in Your App
Attestation and monitoring is not a component you install. It ships inside the Tapaya Accept SDK and inside the
Tapaya Terminal plugin app, it starts with Accept.initialize(), and it runs for as long as the SDK is alive.
There is no configuration flag, no opt-out, and no mode that relaxes it.
Both halves have to pass independently. Your app hosts the SDK, and the SDK hands every card payment to Tapaya Terminal, which attests itself separately. A device that satisfies one but not the other cannot take payments.
Integrating attestation into your app
| Obligation | What it looks like in code |
|---|---|
| Initialize once, early | Accept.initialize(context, isProduction = true) in your Application class. |
| Declare the real environment | isProduction follows your build type, never a value hardcoded for convenience. |
| Keep Tapaya Terminal installed and activated | Check Accept.plugin.isInstalled(), then Accept.plugin.activateTerminal(), before taking a payment. |
| Treat a refusal as final | Report it to the merchant and stop. Do not retry, and do not fall back to another code path. |
See Mobile SDK Integration for the full API surface behind each of these.
Deploying in a production-ready configuration
A production build must not be debuggable, must not log, and must not weaken transport security. The SDK enforces most of this on its own: a debuggable build, or an attached debugger, stops it from initializing at all.
| Setting | Development | Production |
|---|---|---|
android:debuggable | true | false |
Accept.initialize(isProduction = …) | false | true |
Accept.setDebugLoggingEnabled(…) | true | false |
| Signing key | debug keystore | release keystore |
| R8 / ProGuard | off | on, with the SDK's consumer rules intact |
| Network security config | may trust user-installed CAs | no user CA trust, no pinning bypass |
| USB debugging on the device | on | off |
Drive the environment from the build rather than editing it by hand before a release:
Accept.initialize(context = this, isProduction = !BuildConfig.DEBUG)
Accept.setDebugLoggingEnabled(BuildConfig.DEBUG)Compliance
A build that ships with debugging enabled, with debug logging left on, or with certificate pinning bypassed is outside the configuration Tapaya Accept is certified in, whether or not it still processes payments. Confirm each row of the table above before every production release.
Platform preconditions
Every check above depends on a capability of the host device. Supported Devices lists each requirement, why attestation needs it, and what happens when it is missing. Two of them shape hardware selection:
- Android 11 is a hard floor. Devices below it cannot run the SDK at all. Several dedicated SoftPOS models still ship on Android 7 to 9 with no upgrade path, so confirm the OS version of the specific unit rather than the model family.
- Google Mobile Services is optional. Where GMS is present, the SDK adds the Play Integrity API verdict to its own checks. Dedicated terminals shipped without GMS, common from vendors such as Sunmi and iMin, are fully supported.
When a check fails
A failed check is terminal for that device, not a transient error to retry. The SDK refuses to initialize, or refuses to process a transaction when the violation appears mid-session. Nothing in your integration can override that, and attempting to bypass it puts your deployment outside its certified configuration.
Handle it as you would an unrecoverable device fault: tell the merchant the device cannot take payments, and route them to support. Do not retry in a loop, and do not degrade to a different payment path.
Developer Responsibilities
While the SDK handles the heavy lifting, you as the integrator must ensure:
- Do not disable security warnings: Do not attempt to bypass SSL pinning or root detection in production builds.
- Keep the SDK updated: Security patches are released regularly. Ensure your app uses the latest version of the Tapaya Accept SDK.
- Obfuscate your app: Use ProGuard or R8 on your own application code to prevent exposure of API keys or logic that interacts with the SDK.
# The Tapaya Accept SDK includes its own consumer rules, but ensure you do not strip them
-keep class com.tapaya.** { *; }Reporting a Security Incident
If you discover a security vulnerability or suspect a security incident involving the Tapaya Accept SDK or your integration, contact us at security@tapaya.com. Please include as much detail as possible: steps to reproduce, affected SDK version, and device information where applicable.