How to Get the Tap to Pay on iPhone Entitlement, Step by Step

Generate an iOS checkout interface with an AI coding tool like v0 or Bolt, wrap it in a native shell, and try calling Apple’s ProximityReader framework to accept a contactless credit card. Your app will crash immediately. Apple locks down the NFC chip for payment acceptance tighter than almost any other hardware feature on iOS. You can't just import a library, drop in an API key, and start reading Visa cards.

To add Tap to Pay to your app, you have to apply for and obtain the Tap to Pay on iPhone entitlement directly from Apple—twice. You apply once for a restricted development sandbox, and a second time for production distribution after proving your app meets strict user experience and security rules.

We went through this entire certification process to build Final Station, our native POS app. If you're building your own point of sale from scratch, here is the exact path to getting the com.apple.developer.proximity-reader.payment.acceptance entitlement approved, what hardware it actually runs on, and how to get past App Review.

What Do You Need Before Applying for the Tap to Pay on iPhone Entitlement?

TL;DR: Before touching Apple’s request form, you must integrate a supported Payment Service Provider (PSP) like Stripe Terminal or Adyen, and your Apple Developer account must be registered as an Organization with a verified D-U-N-S number.

While iPhones can accept contactless cards directly via built-in NFC, iPad POS setups always require a certified external card reader.

The Tap to Pay on iPhone entitlement is a special permission from Apple allowing an iOS app to use the ProximityReader framework and the device's built-in NFC hardware to read contactless payment cards and digital wallets.

You can't talk directly to the card networks through Apple’s ProximityReader API on your own unless you're a certified Payment Service Provider (PSP). Developers, agencies, and SaaS platforms have to partner with an Apple-approved PSP and embed their Tap to Pay on iPhone SDK inside the app. Apple’s entitlement just unlocks the hardware gate so your PSP's SDK can talk to the iPhone's Secure Element.

1. Choose Your PSP SDK

Your PSP dictates your onboarding timeline and your architecture. In our guide on how to accept card payments in your own POS app, we break down the major SDK options into two camps:

• Self-Serve (e.g., Stripe Terminal): Create a Stripe account today, install the Stripe Terminal iOS SDK, and apply for the Apple entitlement immediately. There are no volume minimums to start testing.

• Enterprise / Selective (e.g., Adyen, Worldpay, Fiserv): Platforms like Adyen power massive scale. We built Final Pay on Adyen's infrastructure across 24+ countries, though going direct to Adyen for a single custom app involves underwriting, commercial contracts, and volume commitments.

Initialize your PSP relationship first. Apple’s application form requires you to name the exact PSP you're using, and they cross-reference it.

2. Upgrade to an Apple Developer Organization Account

Individual Apple Developer accounts ($99/year tied to a personal Apple ID) are ineligible for the Tap to Pay on iPhone entitlement. Apply from an Individual account and Apple will reject the request.

Your developer account must be enrolled as an Organization. Converting an Individual account or registering a new Organization account requires:

• A legal business entity (LLC, Corporation, etc.). Sole proprietorships are often flagged or pushed back into Individual status depending on the jurisdiction.

• A D-U-N-S Number assigned by Dun & Bradstreet. It's free to request through Apple’s D-U-N-S lookup tool, though verification takes several business days or weeks if your incorporation documents are brand new.

• Legal binding authority for the person signing the agreements.

3. Know the Hardware Limits (No iPads Allowed)

Make sure your hardware plan matches Apple’s hardware reality. Tap to Pay on iPhone requires an iPhone XS or later running a supported iOS version.

It never works on iPad. iPads lack the NFC hardware and Secure Element configuration required for contactless card acceptance. We talk to restaurant owners and agency founders who spend weeks designing a countertop iPad POS expecting staff to tap customer cards directly on the tablet glass. If your Station runs on an iPad, you still need an external certified Bluetooth reader or dedicated POS terminal, like our Final Move reader or S700 Station, to take the payment.

The Account Holder Trap: Who Can Submit the Request

Once your Organization account is active, don't hand this task off to a junior iOS engineer or an external freelancer. Only the Account Holder of the Apple Developer Organization can submit the Tap to Pay on iPhone entitlement request form.

The initial development entitlement only runs on physical iPhones connected directly via Xcode—simulators and TestFlight builds aren't supported until production approval.

Even if a team member has the Admin role in App Store Connect with full access to certificates, identifiers, and provisioning profiles, Apple blocks them from opening the request form. Every organization has only one Account Holder, usually the founder, CTO, or legal signatory who set up the account.

For an agency building a bespoke POS app for a client, this creates a recurring operational headache. Either the client sets up their own Organization account, gets a D-U-N-S number, and has their owner fill out the technical entitlement forms over a screen-share with you, or you publish their custom app under your agency’s developer account. That second route violates App Store guidelines if the app is strictly for a single client's internal or branded use.

Filling Out the Request Form: Naming Your PSP and Regions

When the Account Holder logs into the Apple Developer portal and opens the Tap to Pay on iPhone entitlement request form, the questions are brief, but accuracy matters.

A compliant Tap to Pay flow guides the customer to hold their card horizontally at the top of the iPhone for an instant read.

You'll need to provide:

1. Your App’s Bundle ID: The exact explicit Bundle ID (e.g., com.yourcompany.pos) registered in your developer portal. Wildcard Bundle IDs aren't allowed.

2. Your Chosen PSP: Select your payment service provider from Apple's list (such as Stripe or Adyen).

3. Target Regions: Every country where you plan to deploy Tap to Pay on iPhone. Only select countries where your chosen PSP actually supports Tap to Pay on iPhone and where Apple has launched the program. Requesting unsupported regions delays approval.

4. Distribution Method: Whether you're distributing publicly on the App Store or privately as an Unlisted App / Custom App via Apple Business Manager.

Apple manually reviews this initial request before your team can even begin testing on a device.

Limits of the Development Entitlement

Approving your initial form doesn't mean Apple is giving you permission to ship your app. You only get a development-only entitlement.

To turn it on, go into your Apple Developer account under Certificates, Identifiers & Profiles, select your App ID, navigate to the Additional Capabilities tab, and check the box for Tap to Pay on iPhone (Development). Then regenerate your provisioning profiles and add the com.apple.developer.proximity-reader.payment.acceptance key to your .entitlements file in Xcode.

Knowing the walls around this development entitlement will save your engineering team days of confusion:

• Direct Xcode Builds Only: You can only build and run the app on physical iPhones (iPhone XS or later) connected via Xcode using a development provisioning profile.

• No TestFlight: Archive your build and try uploading it to TestFlight with the development entitlement attached, and App Store Connect will reject the binary immediately. TestFlight requires a distribution provisioning profile. Your account doesn't have the distribution entitlement yet.

• No simulator support: The iOS Simulator in Xcode cannot emulate the Secure Element or NFC payment reads. You must test on a real iPhone.

• Sandbox / Test Cards: Depending on your PSP SDK, you'll use either simulated sandbox reader modes or specific test cards to trigger the Apple Tap to Pay payment sheet.

Meeting Apple's Tap to Pay User Experience Requirements

TL;DR: Apple won't grant your production distribution entitlement until you verify that your app follows their strict Human Interface Guidelines for Tap to Pay, including merchant education, checkout button labeling, and post-transaction receipts.

Apple treats the Tap to Pay sheet as a protected system experience. Because iOS renders the payment sheet outside of your app's view hierarchy to prevent malicious apps from skimming PINs or spoofing the screen, Apple enforces strict rules on what happens right before and right after that sheet appears.

Before requesting the production entitlement, your app must implement four UX requirements:

1. Merchant Terms & Education: On first launch or setup, the merchant has to link their Apple ID to their merchant account via the PaymentCardReader session APIs. You also have to provide built-in educational screens or prompts showing the cashier how to accept a tap payment. Specifically, they need to see how to position a physical card horizontally at the top of the iPhone versus holding an Apple Watch or iPhone near the reader area.

2. No Delay Before the Sheet: When the cashier taps your "Tap to Pay" or "Card" button at checkout, initialize the session in the background beforehand using the prepare() method so the system payment sheet pops up fast. If your app stalls on a generic spinner while warming up the reader at every checkout, Apple’s review team will flag it.

3. Clear Checkout Options: Your checkout screen must clearly show that contactless cards and digital wallets are accepted, using Apple's approved terminology and iconography. Never call the feature "Apple Pay Acceptance." The merchant is accepting contactless cards and Apple Pay via Tap to Pay on iPhone.

4. Clear Result Handling and Receipts: Once the system sheet closes and returns a payment read result to your PSP SDK, your app must immediately show whether the payment succeeded or failed, display the final amount, and offer a customer receipt via email, SMS, QR code, or thermal print.

Re-Requesting for Distribution, TestFlight, and App Review

Once your app works on a local test iPhone and meets all of Apple's UX requirements, the Account Holder has to return to Apple’s portal to request the distribution entitlement.

Depending on your PSP and region, Apple's secondary review requires confirming your UX compliance, sometimes by submitting demo video walkthroughs or answering questionnaires about your checkout flow. Once Apple grants the distribution entitlement:

1. Go back to Certificates, Identifiers & Profiles in your Apple Developer portal.

2. Enable the production Tap to Pay on iPhone capability on your App ID.

3. Regenerate your App Store distribution provisioning profile.

4. Archive and upload your build to TestFlight.

At this point in your development cycle, you can finally share the app with internal testers or beta merchants via TestFlight. When you submit the app to App Store Review, include working demo credentials and instructions in the App Review notes so the reviewer can walk through your checkout flow and trigger the payment initialization.

Building an Android version of your POS requires a parallel compliance track on Google’s side. You'll need to integrate your PSP's Tap to Pay on Android SDK, require Android 11+ with NFC, enforce android:debuggable="false" in release builds, and pass Google Play Integrity API device attestation so rooted or compromised phones are blocked from reading cards.

Or Skip the Entitlement Entirely: Final's App Already Has It

If you run a vertical SaaS platform, a digital agency, or a business using AI to build a custom checkout workflow, look closely at what you actually want to build. You want custom screens, specific conditional logic, custom forms, or niche inventory rules. You don't want weeks of D-U-N-S verification, provisioning profile debugging, and PSP SDK plumbing.

When we built Final POS, we went through the entire entitlement, security attestation, and hardware certification process on both iOS and Android so you don't have to.

With Final Build (our AI POS builder), you describe the exact checkout flow you want, such as split bills for a 60-seat restaurant, serial-number intake for a repair shop, or multi-Outlet retail checkout, and Build generates a working POS in minutes. Because it runs on real commerce rails rather than generating a hollow web mockup, you deploy that flow directly to Final Station, our native app already live on the App Store and Google Play.

• Tap to Pay is live on day one: Final Station already holds the production Tap to Pay on iPhone entitlement and Android attestation. Turn on **Final Pay** (our Adyen-powered integrated payments), open your custom flow on an iPhone or NFC-equipped Android phone, and take a Tap to Pay payment immediately. Because the buttons at checkout come directly from your flow, Tap to Pay appears right alongside options like Cash, and the phone itself becomes the reader.

• Works on iPads, Kiosks, and Desktops too: If you want an iPad countertop setup where Apple blocks Tap to Pay on the glass, pair a merchant-owned Final Move Bluetooth reader, a Final Touch smart terminal, an all-in-one S700 Station, a Final Register CFD (our 10.1" HD customer display with USB plug-and-play and NFC Tap on Glass), or an Adyen S1U2 unattended terminal for self-service kiosks without writing a single line of hardware SDK code.

• Transparent rates, zero monthly software fees: Building in Final is free (with 1,000 free build credits per day, up to 5,000 a month), and Final Station is included at $0/month. Cash is always $0, and in-person card rates on Final Pay are flat: 1.99% + $0.10 CAD in Canada (Interac debit at 0.5% + $0.07), 0.99% + €0.10 in Europe, and 2.49% + $0.10 in the US and worldwide, with next-day payouts included.

• Resell under your own brand: If you run an agency or SaaS platform, Final Scale lets you package your custom flows into Plans, onboard client merchants under your own organization, set custom processing rates, and earn recurring residuals (the margin between the rate you set and your base rate) on every transaction, all without touching an Apple Developer account.

Your Next Step

If you're committed to compiling and shipping your own standalone iOS binary, stop writing UI code today. Have your company's Account Holder verify your Apple Developer Organization status and submit the initial development entitlement request now. Waiting until the end of your sprint to apply will stall your launch by weeks.

If you'd rather skip the Apple bureaucracy and have your custom POS taking live contactless cards before lunch, open Final Build, describe your checkout flow, and deploy it straight to the iPhone in your pocket.