Apple reviews Tap to Pay on iPhone apps against a specific set of user-experience requirements before granting the distribution entitlement (required for TestFlight and the App Store, see Apple entitlement setup). Build these requirements into your app from the start rather than retrofitting them after review feedback.
To request the distribution entitlement, reply to Apple's original entitlement email once your app meets the requirements below. The process usually takes one to two weeks and may include a round or two of feedback. For Apple-side questions during the process, contact ttpoientitlements@apple.com with your case ID.
These requirements come from Apple. The tables below map each one onto a Finix integration: "SDK" means FinixTapToPaySDK already satisfies it when used as this guide shows, and "Your app" means you build it.
| Requirement | Handled by | Notes |
|---|---|---|
| Offer Tap to Pay on iPhone only on compatible devices (iPhone XS or later). | Your app + SDK | Gate every entry point on FinixTapToPay.isSupported(). |
| Set an appropriate iOS deployment target. | Your app | The SDK requires iOS 18.1+. Either set your target to 18.1+, or guard Tap to Pay on iPhone code paths for earlier targets. |
| Warm up the reader at launch or foreground. | Your app + SDK | Call prepareReader() once linked (Prepare the reader); autoPrepareOnForeground re-warms on foreground. |
| Read Terms and Conditions acceptance from Apple, never a local flag. | SDK | isAccountLinked() queries Apple; don't cache acceptance in your own storage. |
| If Tap to Pay on iPhone is your app's sole payment method, restrict downloads to capable devices. | Your app | Add to Info.plist: see below. |
| Use Face ID / Touch ID for merchant login (recommended). | Your app | Makes repeat checkout faster for merchants. |
| Follow the Human Interface Guidelines and Apple's Tap to Pay on iPhone marketing guidelines. | Your app | HIG · Marketing guidelines. |
<key>UIRequiredDeviceCapabilities</key>
<array>
<string>iphone-ipad-minimum-performance-a12</string>
</array>| Requirement | Handled by | Notes |
|---|---|---|
| Tap to Pay on iPhone access is easy to discover for a new user. | Your app | Prominent "Enable Tap to Pay on iPhone" / "Get started" entry. |
| Digital onboarding completes in under 15 minutes for most users. | Your platform | Measured from information submission to first accepted payment. |
| A clear, unambiguous action triggers Terms and Conditions acceptance. | Your app + SDK | Your button calls linkAccount(); the SDK presents Apple's sheet. |
| Only an admin or authorized user can accept the Terms. | Your app | Gate the link flow by role; the SDK has no role concept. |
| Non-admin users are told to contact their admin. | Your app | Show messaging instead of the link flow. |
| Tap to Pay on iPhone can be enabled outside checkout (for example, in settings) and from the checkout flow. | Your app | Both paths lead to the same link flow. |
| All eligible users see a Tap to Pay on iPhone announcement at least once. | Your app | Splash screen or push notification. |
| Show configuration progress while Tap to Pay on iPhone is being set up. | Your app | Indeterminate progress while awaiting prepareReader(); the SDK does not report percentages. |
| A "try it out" moment after setup (recommended). | Your app | Prompt a first practice transaction once the reader is ready. |
| Requirement | Handled by | Notes |
|---|---|---|
| Education screens appear after Terms acceptance. | Your app | Teach the merchant how to take a tap payment. |
| Education is re-accessible later (Settings or Help). | Your app | Keep a permanent entry point. |
| On iOS 18 and later, prefer Apple's built-in education UI. | Your app | Present Apple's ProximityReaderDiscovery directly. Apple keeps its content current and localized, and the SDK does not wrap it. |
| Education demonstrates contactless card acceptance and Apple Pay / digital wallet acceptance. | Your app | Required content if you build custom education screens; use Apple-approved assets. |
| Requirement | Handled by | Notes |
|---|---|---|
| An obvious, prominent Tap to Pay on iPhone button at checkout. | Your app | Visible without scrolling; first among multiple payment options. |
| The button is never hidden, grayed out, or altered based on enablement. | Your app | If not yet enabled, the button starts the enablement flow. |
| Use only Apple's approved symbol if the button has an icon. | Your app | SF Symbols wave.3.right.circle or wave.3.right.circle.fill. |
| A processing screen shows after the card read. | Your app + SDK | Drive it from the .processing event (Take a payment). |
| The outcome (approved, declined, timed out) is clearly communicated. | Your app | From the returned result or thrown error. |
| A digital receipt can be offered after every outcome, confidentially. | Your app | SMS, email, QR code, or share sheet (Handle the result). |
import SwiftUI
Button {
startTapToPayCheckout()
} label: {
Label("Tap to Pay on iPhone", systemImage: "wave.3.right.circle.fill")
}When you launch Tap to Pay on iPhone to your users, Apple expects a launch email to eligible users, an in-app splash, and a push notification, using copy aligned with Apple's Tap to Pay on iPhone marketing guidelines and Apple-approved assets.
Apple asks for screen recordings with the distribution entitlement request. Record with a second device where possible. Apple wants to see three flows:
New user flow
- New merchant onboarding, including account creation and any identity verification.
- How Tap to Pay on iPhone is introduced to the new merchant, and the Terms and Conditions acceptance.
- The education screens after acceptance, and where education can be found again later.
- The configuration progress indicator, through to setup completion.
Existing user flow
- Where an existing user discovers Tap to Pay on iPhone (splash, notification, settings).
- Terms acceptance, education, and, if the user skips ahead, the progress indicator before first use.
- The Tap to Pay on iPhone button visible at checkout even before enablement.
Checkout flow
- Building a payment (amount entry or cart), the payment options, and the Tap to Pay on iPhone button.
- A complete tap transaction: processing screen, outcome screen, and the receipt option.
Re-recording the Terms acceptance requires an unlinked state. The most reliable option is a device and Apple Account pair that has never linked. Deleting and reinstalling the app usually works too, but the link can survive a reinstall, so check isAccountLinked() before recording. true means you're still linked, and false isn't a guarantee, since the check also returns false on errors. See unlinking.
Apple imposes additional requirements in some regions, including PIN entry support with accessibility guidance, and a fallback payment method where many cards cannot complete contactless transactions. SDK 1.0.0 targets US merchants and does not support PIN entry. If you plan to deploy outside the US, contact Finix Support first to confirm regional availability.
Next: Troubleshooting and support.