Launching on the App Store

Everything you need to do with Apple — separate from your Koard integration — before your app can go live to merchants.

Track your progress in Launch Readiness inside the Koard MMS — it mirrors this guide step by step.

Why this matters

Four of the most common rejection reasons we see from Apple Review:

1. Submission videos don't show how a merchant accepts Apple's Terms & Conditions or links the merchant account.
2. No in-app merchant education — the developer planned to train merchants 1:1 in person. Apple requires in-app education on top of whatever else you do.
3. The prepare() call isn't implemented, which means the first tap-to-pay attempt in front of a real customer takes 30–40 seconds.
4. Button copy mixes "Tap to Pay" with "Tap to Pay on iPhone" — Apple is strict about the full product name.

None of that is a Koard problem. All of it is an Apple-side gate, and it routinely costs developers weeks they didn't plan to spend. This guide and the in-MMS checklist exist so you find these things in week one of design — not in week one of submission.

The launch journey

Each step is a distinct gate. You cannot skip any of them.

Pick your distribution path first

Apple has different requirements depending on how your app reaches merchants. Decide before you design any screens — the distribution path determines which checklist items are required for you.

Most underused: Custom App and Unlisted App, which carry lighter requirements for enterprise deployments. Apps that ship via MDM to managed devices are typically a fit for Unlisted.

If you're not sure, the Koard solutions team can talk it through — but pick before you start designing screens.

Two entitlements, not one

The in-app experience Apple requires

Apple inspects four moments in your user flow. Each has its own checklist covered in the sections below. Together they form the bulk of the v1.5.1 review.

The prepare() call — don't skip this

Koard's SDK exposes this as koard.tapToPay.prepare(). It warms up the reader. The first call after install takes 30–40 seconds. Subsequent calls take 5–6 seconds, once every 24 hours.

Where to call it: at app launch and every time the app comes to the foreground.

Where not to call it: at checkout. If you do, the first time your merchant tries to take a payment in front of a real customer, they will stand there for 40 seconds. Apple flags this in reviews.

It's checklist item 1.4. Implement it on day one. Apple's reviewers flag this often.

// AppDelegate.swift
func applicationDidBecomeActive(_ application: UIApplication) {
    Task {
        try? await koard.tapToPay.prepare()
    }
}

Terms & Conditions: two paths

There are exactly two ways a merchant can accept Apple's Tap to Pay T&C. Pick one based on your distribution path.

The three required videos

Apple requires three video walkthroughs as part of the Publishing Entitlement review.

Submitting to App Store Connect

For Public, Unlisted, or Custom App distribution, passing the Publishing Entitlement review is not the end. Your app then goes through standard App Store Review plus a Tap to Pay-specific review.

In your App Store Connect submission notes, include:

• A declaration that you are using the Tap to Pay on iPhone entitlement.
• A description of your use case (e.g. "a point-of-sale app for SMB merchants").
• A test account that works. Apple says "a vast majority of rejections are due to test accounts not working properly." Validate on a fresh device before submitting.
• A link to your video walkthrough and high-fidelity wireframes of your checkout experience.
• If your app is geo-fenced or uses a feature flag for Tap to Pay — declare that explicitly.
• If Tap to Pay is your only acceptance method, set UIRequiredDeviceCapabilities to include iphone-ipad-minimum-performance-a12 so incompatible devices cannot download the app.

Common pitfalls

After approval: pilot, then GA

Apple strongly recommends piloting with a small group of representative merchants before flipping to general availability. Two options:

• TestFlight — invite-only, requires the Publishing Entitlement.
• Feature flag — ship the binary to GA with Tap to Pay hidden behind a backend flag you control. This is the path Apple recommends for existing apps, because most users will already have the updated version when you flip the flag. If you go this route, declare it in your App Store Connect submission, and do not update your App Store product page with Tap to Pay messaging until you flip the flag.

Apple ships a pilot questionnaire in the Getting Started PDF (Appendix). Use it.

Quick reference links

• Apple Tap to Pay on iPhone developer site
• Request the entitlement
• Human Interface Guidelines — Tap to Pay on iPhone
• Apple Marketing Guidelines
• ProximityReaderDiscovery API (iOS 18+)
• App Store Review Guidelines

Where to get help

• In-MMS checklist — Launch Readiness in your Koard dashboard mirrors this guide section by section.
• Apple entitlement questions — reply on your existing applepayentitlements@apple.com thread, citing your Case ID.
• PSP-side questions (T&C from Apple vs local, ABC tokens for enterprise, prepare() semantics) — your Koard solutions contact.

See also

• Setting Up the Entitlement for Tap to Pay on iPhone - Request and configure the Apple development entitlement
• Adding Support for Tap to Pay on iPhone - Configure Xcode and run your first test transaction
• Getting Ready for Production - Set up Xcode schemes and API keys for your production build
• Apple Best Practices and Guidelines - UX patterns, ProximityReader usage, and security practices
• Running Payments - SDK reference for payment flows

This guide reflects Apple's published requirements as of March 2025 (App Review Checklist v1.5.1) and September 2023 (Getting Started v1.2). Apple updates these documents periodically. If you see a discrepancy, the Apple source wins — please flag it to us.