Troubleshooting
Real-world fixes for issues merchants commonly hit when enrolling devices or running their first tap. If a device fails the SDK eligibility check, see Supported Devices & NFC Tap Location. For SDK error codes returned during a transaction, see SDK Response Codes.
What you learn
In this guide, you'll learn:
- How to fix the "tap was immediately cancelled" issue
- How to resolve enrollment failures caused by device clock drift
- Which device settings must be enabled before a merchant's first transaction
- A pre-flight checklist to run before contacting Koard support
Tap is Immediately Cancelled
Symptom
The merchant enrolls successfully and the SDK reports the device as eligible. When they attempt their first sale, the reader shows "Present card", but the moment the customer taps, the transaction is immediately cancelled — the SDK emits an Abort (or OnFailure) before the card is read.
This has been observed across several Android devices, with Samsung Galaxy S21 being the most common — but any Android device that exposes a separate "NFC and contactless payments" (or similarly named) toggle can hit it.
Cause
Many Android devices ship with two distinct NFC settings:
- NFC — the basic NFC radio toggle (enabled by default on most devices).
- NFC and contactless payments — a separate setting that authorizes the device to use NFC for payment-related Host Card Emulation (HCE) and Tap to Pay flows. Different OEMs label this differently (e.g. "NFC and contactless payments", "NFC and contactless transactions", "Contactless payments").
The SDK eligibility check verifies that NFC hardware is present and the radio is on, which is why enrollment and the eligibility check both pass. However, if the secondary "NFC and contactless payments" setting is disabled, the Visa Tap to Pay Ready kernel cannot complete the contactless card read — the device's payment subsystem blocks the read and the transaction is cancelled before any card data is exchanged.
Fix
On the merchant's device:
- Open Settings
- Tap Connections (or Connected devices depending on the OEM and Android version)
- Tap NFC and contactless payments (sometimes labeled NFC and contactless transactions or simply Contactless payments)
- Ensure the master toggle is On
- Optionally set Contactless payments → Default payment app to your merchant app, or leave it as the system default if your app does not require the system payment role
After enabling the setting, retry the sale. No re-enrollment is required.
Why the eligibility check doesn't catch this: getKiCEligibility() verifies that NFC hardware exists and the system NFC radio is enabled. The OEM-specific "contactless payments" toggle gates a higher layer (the payment HCE subsystem) and is not visible to the eligibility API. If a merchant sees taps cancelled instantly, always confirm this setting before deeper debugging.
If "NFC and contactless payments" is enabled and the tap is still cancelled instantly, check whether a wallet app (Samsung Wallet, Google Wallet, etc.) is set as the default and is intercepting the tap. Temporarily clear the default payment app under NFC and contactless payments → Contactless payments, then retry.
Enrollment Fails or Returns Errors
Symptom
Calls to enrollDevice() (or the SDK's enrollment flow) fail with errors such as:
VACEnrollmentErrorAuthenticationFailed(status code7)AttestationFailed(status code24)CouldNotAttestError- Generic prepare errors in the
7–51range
The merchant sees an "Enrollment failed" screen and cannot proceed to take their first tap.
Cause
Enrollment establishes a secure channel between the device and the Visa Acceptance Cloud (VAC). That handshake includes a device attestation step that is sensitive to three things:
- Developer mode is enabled — most enrollment endpoints reject devices with developer options on, because the device cannot produce a trustworthy attestation.
- The device clock has drifted — VAC verifies signed timestamps during the handshake. If the device clock is off by more than a few minutes (a "clock drift" issue), signatures fail to verify and attestation is rejected. This is most common on devices that have been offline for a long time, recently factory-reset, or have automatic time disabled.
- Google Play Protect is disabled — Play Protect provides the integrity signals VAC uses to attest the device. With Play Protect off, the attestation payload is incomplete and enrollment is rejected.
Fix
Walk the merchant through all three checks before retrying enrollment:
1. Disable Developer Mode
- Open Settings → System → Developer options
- Toggle Developer options to Off
- If the option is missing entirely, developer mode is already off — proceed to the next step
If developer mode was on, restart the device after disabling it.
2. Enable Automatic Date & Time
- Open Settings → General management → Date and time (Samsung) or Settings → System → Date & time (stock Android)
- Toggle Automatic date and time to On
- Toggle Automatic time zone to On
- Wait a few seconds for the device to sync with the network time source
This corrects clock drift and is the most common fix when enrollment fails on a device that previously worked.
3. Enable Google Play Protect
- Open the Google Play Store app
- Tap your profile icon (top right) → Play Protect
- Tap the gear icon (settings) in the top right of the Play Protect screen
- Toggle Scan apps with Play Protect to On
Play Protect must be enabled for the device attestation step to succeed. If the merchant cannot enable Play Protect (for example on a device without Google Mobile Services), the device is not eligible for Tap to Pay.
After all three checks pass, restart the device and retry enrollment. If the SDK still returns an enrollment error, capture the statusCode and errorType and consult the SDK Response Codes reference.
Why clock drift matters: The VAC attestation handshake relies on signed timestamps to prevent replay attacks. The SDK's enrollment flow includes a fresh nonce and a device-side timestamp; if the device clock is more than a few minutes off the server clock, the server rejects the timestamp and the handshake fails — often surfacing as a generic AuthenticationFailed (code 7) or AttestationFailed (code 24). Enabling automatic time syncs the device against a network time source and eliminates the drift.
Pre-Flight Checklist
Before contacting Koard support about a device that "won't take a tap" or "fails to enroll", confirm all of the following on the merchant's device:
- Device is running Android 12 (API 31) or later
- NFC is enabled in Settings
- NFC and contactless payments is enabled (where present)
- Developer mode is off
- Automatic date and time is on
- Google Play Protect is enabled
- Google Play Services is installed and up to date
- Visa Tap to Pay Ready kernel app is installed from the Play Store
- Device is not rooted and is not running a custom ROM
getKiCEligibility()returns no failures
If every item is checked and the device still fails, gather the following before contacting support:
- Device make, model, and Android version
- Koard SDK version (the version of
koard-android/ the Koard Merchant SDK your app is built against) - The
statusCodeandstatusCodeDescriptionfrom the failingKoardTransactionResponse, or theKoardErrorTypefrom the thrownKoardException - A log excerpt from the time of the failure (the SDK emits structured events via
KoardTimeEventLogger)

