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:

  1. NFC — the basic NFC radio toggle (enabled by default on most devices).
  2. 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:

  1. Open Settings
  2. Tap Connections (or Connected devices depending on the OEM and Android version)
  3. Tap NFC and contactless payments (sometimes labeled NFC and contactless transactions or simply Contactless payments)
  4. Ensure the master toggle is On
  5. 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:

  • VACEnrollmentError
  • AuthenticationFailed (status code 7)
  • AttestationFailed (status code 24)
  • CouldNotAttestError
  • Generic prepare errors in the 751 range

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:

  1. Developer mode is enabled — most enrollment endpoints reject devices with developer options on, because the device cannot produce a trustworthy attestation.
  2. 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.
  3. 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

  1. Open Settings → System → Developer options
  2. Toggle Developer options to Off
  3. 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

  1. Open Settings → General management → Date and time (Samsung) or Settings → System → Date & time (stock Android)
  2. Toggle Automatic date and time to On
  3. Toggle Automatic time zone to On
  4. 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

  1. Open the Google Play Store app
  2. Tap your profile icon (top right) → Play Protect
  3. Tap the gear icon (settings) in the top right of the Play Protect screen
  4. 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 statusCode and statusCodeDescription from the failing KoardTransactionResponse, or the KoardErrorType from the thrown KoardException
  • A log excerpt from the time of the failure (the SDK emits structured events via KoardTimeEventLogger)