Going to Production on Android
Going live on Android has three parts: a signed release build that passes the device integrity checks, a production merchant configuration, and Google Play's review. Use this guide with SDK 1.0.7 after the Android Quickstart.
Complete the UAT checks in sections 1 and 2 of the Launch Checklist before you start. Then work through this page in order.
| Step | What you do | Section |
|---|---|---|
| 1 | Learn what Google Play reviews and prepare it. | Google Play review |
| 2 | Confirm the Tap to Pay requirements that the device enforces. | Tap to Pay requirements |
| 3 | Create the production merchant configuration. | Production configuration |
| 4 | Build and sign the release. | Release build |
| 5 | Check the release on a production device. | Production device |
| 6 | Run live payments and reconcile them. | Payments and settlement |
| 7 | Publish through Google Play. | Publish |
| 8 | Market the feature inside the brand rules. | Brand and marketing |
| 9 | Support your merchants after launch. | Merchant support |
| Production setting | Value |
|---|---|
| Dashboard | app.koard.com |
| API | https://api.koard.com |
| SDK | 1.0.7, KoardEnvironment.PROD, production app key |
1. Google Play Review: Process and Guidelines
Google reviews every new app and every update against its Developer Program Policies before it reaches merchants. Android has no Tap to Pay entitlement to request and no separate Tap to Pay review. A payment app needs these items ready in Play Console:
| Item | What Google needs |
|---|---|
| Financial features declaration | Required for every app. Declare your app's financial features on the App content page, under Policy and programs. You cannot publish updates until it is complete. |
| Financial services policy | Read it before you submit and confirm that your app and listing comply. |
| Sign-in details | Reviewers must be able to get past your login. Provide a merchant login that works in the build you submit, and put any extra steps in the instructions field. |
| Privacy policy, data safety, content rating, target audience, and ads | The standard declarations in Prepare your app for review. |
Plan for these timings:
- Review time. Google says reviews can take up to seven days, and longer in exceptional cases. Submit before your launch date, not on it.
- New personal developer accounts. Google requires a closed test with at least 12 testers for 14 days before a new personal account can publish to production. See Google's testing requirements. Organization accounts are not subject to this rule.
2. Tap to Pay Requirements on Android
These requirements are not reviewed by a person. The device enforces them when a merchant enrolls, so a build that misses one fails in the merchant's hands.
| Requirement | Detail |
|---|---|
| Android version | Android 13 or later. |
| Hardware | Built-in NFC and a hardware-backed keystore. |
| Google services | Google Play services up to date and Google Play Protect enabled. |
| Device integrity | Release-signed build, locked bootloader, no root, and no custom ROM. A debug build installed from Android Studio is rejected at enrollment, even on supported hardware. |
| Developer options | Off before enrollment and payments. |
| Date and time | Set automatically. Enrollment fails when the device clock is wrong. |
| Installation | From Google Play. Visa's requirements do not allow a sideloaded merchant app, so distribute the app to merchants through Google Play. |
| Visa Tap to Pay Ready | Version 25.06.10 or later, installed from Google Play or through the SDK's install flow. |
Three of these need handling in your app:
- Visa Tap to Pay Ready. The Koard SDK uses this app to read the card. A merchant installs it once and never opens it. There is no fee, nothing to register with Visa, and no extra key for production. Offer the SDK's install action so merchants do not have to find it in Google Play.
- NFC. An app cannot turn NFC on. Detect that it is off and send the merchant to the device settings.
- Developer options. Card reads do not work while developer options or USB debugging are on, in UAT or production. Rooted devices and devices with an unlocked bootloader are not supported. You can install a build with them on, then turn them off before enrollment and payments. Use logcat after that if you need logs.
Supported Devices has the full requirement list and the tested devices. If your activity is locked to portrait, also declare the optional portrait feature described in Installing the SDK, so Google Play does not hide your app from point of sale devices.
3. Provision Production Configuration
Koard invites you to the production dashboard once your agreement is in place. Use Koard Production and https://api.koard.com. Create the production merchant, identify its production processor configuration, board the terminal with the processor's live identifiers, link a location, and create merchant credentials. Follow the same dashboard or API setup you used in UAT. UAT IDs and credentials do not work in production: the processor configuration ID is different, and the terminal uses the merchant's production processor credentials.
Initialize the SDK with a production app key and KoardEnvironment.PROD. Create the key in production with the payments:tap-android permission, as described in Getting an API Key. Keep backend API keys on your server and keep real credentials out of source control.
4. Build the Release Variant
Resolve com.koard:koard-android-sdk:1.0.7 from Maven Central. The public demo's production flavor is prod; use assembleProdRelease for its release APK. Configure signing through your build or CI process, with the signing material kept outside source control.
SDK 1.0.7 includes consumer rules for R8. Test the minified release build that you will distribute; a debug build is not sufficient verification. Clean and rebuild any JVM, Flutter, or React Native wrapper after you change the SDK version or payment method signatures. See Minification and R8.
Use Android's app signing guide for release signing, and Play App Signing when you distribute through Google Play.
5. Validate a Production Device
Use a supported physical device that meets every requirement in section 2. Turn developer options off before enrollment, before switching locations on an enrolled device, and before payments.
Prefer a device that was never enrolled in UAT. If you reuse a UAT device, reset the SDK with deinit() before you initialize it for production, as described in SDK Lifecycle, so it does not carry the UAT enrollment over.
Log in with the production merchant, select and display its active location, and complete enrollment. Block payments until readiness passes. On the release build, test logout, app restarts, lost connectivity, and merchant and location changes.
6. Verify Payments and Settlement
Coordinate live testing with your processor and Koard contact. Production payments move real money. Inspect the resulting status and amount, then run the reversal or refund that matches the recorded transaction state.
Test the outcomes in your plan, including declines, cancellation, partial approval and surcharge decisions where supported, and recovery of a lost response. Verify that signed webhooks are persisted and retried, and reconcile transactions against batch events and processor reports.
The supported Fiserv integration manages batches automatically. TSYS and Elavon support explicit opening. Worldpay creates batches through host capture. Running Batches describes each processor's behavior.
7. Publish Through Google Play
- Upload the signed release to an internal or closed testing track.
- Install that build from Google Play on a supported device and repeat enrollment and a payment. This is the build your merchants receive.
- Complete the App content declarations from section 1, including the Financial features declaration and sign-in details.
- Finish the store listing, then send the release for review.
- Roll out to production. Google's publishing overview explains how to control when an approved release goes live.
After release, monitor payment outcomes and settlement, and keep a way to pause new payments if a problem appears. Reconcile uncertain in-flight payments before another submission.
8. Brand and Marketing Guidelines
| Rule | What it means for you |
|---|---|
| Google Play badge | Use Google's badge artwork unchanged when you link to your listing, and follow the size, clear space, and placement rules in Google's badge guidelines. |
| Card brands and the contactless symbol | Acceptance marks belong to the card networks, and the contactless symbol belongs to EMVCo. Get the artwork and usage rules from your processor. Do not redraw them. |
| Keep Apple's assets on iPhone | Apple's Tap to Pay on iPhone name, imagery, and templates apply only to the iPhone app. Do not reuse them for Android. |
| Show the right tap position | Marketing and help content should show the card against the back of the phone, as described in NFC antenna location. |
9. Merchant Support
You are the first line of support for your merchants. Koard takes the issues you cannot resolve: SDK behavior, reader behavior, certification, and infrastructure. Android has no built-in education screens, so your app provides them. Your app also draws the tap screen on Android, so the tap guidance on it is yours to write.
| Merchants need | Provide |
|---|---|
| To learn how to take a payment | In-app screens that show where to hold the card on the back of the phone, and how wallets and PIN entry work. Make them reachable from Settings or Help. Merchant Education lists what to cover. |
| A device that is ready | A setup check that tells the merchant what to fix: install or update Visa Tap to Pay Ready, turn on NFC, turn on Google Play Protect, set date and time to automatic, and turn off developer options. Use the SDK's readiness state to drive it. |
| Someone to contact | Your support contact, shown in the app. |
When a merchant reports a problem, start with Android Troubleshooting and the SDK Response Codes. For anything you cannot resolve, write to support@koard.com with the environment and the merchant, location, terminal, and transaction IDs. Never send card numbers, PINs, API keys, or merchant credentials.
Release Checklist
- Production environment, app key, merchant, processor configuration, terminal, and location agree.
- Signed, non-debuggable, minified release build tested on supported physical hardware.
- Visa Tap to Pay Ready package visibility, installation, NFC lifecycle, and readiness validated.
- Developer options off before enrollment and payments.
- Active location visible in settings and checkout; stale selections cleared after merchant changes.
- Payment outcomes, follow-up operations, response recovery, and settlement reconciled.
- Webhook deliveries persisted before acknowledgment and business failures retried.
- Play Console declarations complete, and the build installed from Google Play tested.
- Merchant education reachable in the app and a support owner assigned.
Next Step
Finish the remaining checks in the Launch Checklist, then release the app.
