If your developer team has been approved to implement Tap to Pay on iPhone, you were granted a managed entitlement configured only for the Development distribution type. When compiling your project for any other distribution type, such as App Store or Ad hoc, the build with fail with errors. You can resolve these errors by contacting the initial provisioning team and asking for production distribution review/validation. For more information on requesting the Tap to Pay on iPhone entitlement, see the documentation below: Setting up Tap to Pay on iPhone https://developer.apple.com/documentation/proximityreader/setting-up-the-entitlement-for-tap-to-pay-on-iphone To request for permission for the App Store and Ad hoc distribution types, please respond to the confirmation email received after your initial entitlement request. The provisioning team will provide the next steps to begin the public distribution review process and eventually approve your app for distribution via TestFlight and the App Store. Note: The only team that manages this entitlement is the same provisioning team that granted you access, so you'll need to follow-up with the same team that approved your initial request to resolve this compilation and archival issue. Once you're approved for App Store distribution, the same steps used to distribute your app via TestFlight will be successful. If you continue to have errors after confirming you've been granted the App Store distribution type for your app configuration, please see the post below, then create a new post for your issue and mention your Feedback ID after following the steps: Gathering Required Information for Troubleshooting Tap to Pay on iPhone https://developer.apple.com/forums/thread/775784 Cheers, Paris X Pinkney |  WWDR | DTS Engineer

We are seeing an issue with a potential duplicate charge issue regarding our app. We have received two transactions with the same originalTransactionId but different transactionIds: Order A: TransactionId: [Redacted_TID_1] OriginalTransactionId: [Redacted_OID_A] ProductId: weekly_subscription PurchaseDate: [Redacted_Timestamp_1] SignedDate: [Redacted_Timestamp_2] Price: [Redacted_Price] CAD Order B: TransactionId: [Redacted_TID_2] OriginalTransactionId: [Redacted_OID_A] ProductId: weekly_subscription PurchaseDate: [Redacted_Timestamp_1] SignedDate: [Redacted_Timestamp_3] Price: [Redacted_Price] CAD Both transactions share the same originalTransactionId, productId, and expiresDate, but the transactionIds are different. We wanna confirm: Were customers charged once or twice for this subscription renewal? If only one charge was made, how should we programmatically determine the “valid” transaction among multiple records with the same originalTransactionId to avoid confusion in our server-side receipt validation? We appreciate any clarification so we can handle this correctly in our backend.

I’m implementing subscriptions and running tests, and I noticed a behavior I’d like to confirm. Plans in the app Basic — Monthly Basic — Annual Premium — Monthly Premium — Annual Test environment Sandbox (where ~1 day ≈ under 1 minute of real time) steps Start Basic (Monthly) using an introductory offer (free trial). Create a crossgrade to Basic (Annual) (scheduled/queued). After receiving a RENEWAL App Store Server Notification indicating the plan will move from trial to paid Basic (Annual), but before the trial actually expires, upgrade the user to Premium (Monthly). Observed behavior (Sandbox) & questions Even though there is still up to ~1 day of trial remaining (≈ under 1 minute in Sandbox), upgrading to Premium (Monthly) immediately ends the trial and activates the paid Premium plan right away. Will this same behavior occur in Production? If yes, is this the expected/acceptable behavior when upgrading during an active trial after a pending crossgrade? Note: If we upgrade to Premium before the RENEWAL notification arrives, the remaining trial time is carried over in our tests. In this flow, we see a RENEWAL notification for Basic (Annual) (moving from trial → paid), but then the user immediately upgrades to Premium (Monthly) and the trial ends at that moment. In Production, would the charge for Basic (Annual) be refunded automatically since the user effectively switches to Premium immediately (and Basic Annual does not remain active)? In Sandbox there’s no real charge, but I want to ensure we won’t see a situation in Production where Basic (Annual) is billed and not refunded, even though the subscription effectively moved to Premium right away. Thanks in advance!

Hello, We are trying to add tap to pay to our app built with react native through expo. When running the command eas build --profile development --platform ios --local I get this error: But when I open the project in XCode I can see that the Tap to Pay capability is enabled: And when I look at my profiles in the apple developer platform, I can see that the profile the error mentioned above has the Tap to Pay entitlement contrary to what it tells me: I don't understand what's happening, can somebody help me? I'm here if you need more informations. P.S.: not sure if it's relevant but, the way we did thing with expo, we have a different bundle identifier and app name according to which environment we are building for (development/preview/production)

大家好！应用程序提交审请时有个问题请教 （非消耗型产品）提示 购卖商品 ID不存在 应该如何解决

Trying to enable TTP and we're a PSP, from everything I'm reading I'm supposed to provide a reader token to our merchants but can't find anything on it. How do I generate this token? All I know is that it's a jwt and there's some header requirements. Documentation mentions the jwt should include a unique merchant identifier. My question is what does the payload and header look like when signing the jwt?

Hi everyone, we’ve been waiting since May 30 for our Tap to Pay on iPhone entitlement to be enabled for distribution, but it’s still only active for development (Case‑ID: 14485444). We submitted: A new video recorded from an external device showing the full checkout flow Updated merchant education using the ProximityReaderDiscovery.Topic.payment(.howToTap) API, as suggested by Apple The team initially said the education was compliant, then said it wasn’t. We fixed everything, sent the updated materials, and haven’t heard back in days. We can’t even upload the app to TestFlight because of this error: Profile doesn't include the com.apple.developer.proximity-reader.payment.acceptance entitlement It’s now been almost a month and a half, and this delay is becoming critical. It’s blocking both internal testing and our production release. We’d really appreciate clarity on: Do we need to submit another request via the form? Or is it enough to reply to the existing email thread? Also, are there any direct contacts or escalation paths we can use? Any help or guidance appreciated

Hi guys, I'm trying to upload my app with Tap to Pay on iPhone functionality. However, I'm getting error message "Profile doesn't include com.apple.developer.proximity-reader.payment.acceptance entitlement." I've confirmed many times that I have the distribution profile with this capability. Any idea what might be the issue? The development environment works perfectly.

Tap to Pay capabilities are enable and I can use in development profile but I cannot make build that I can upload on TestFlight using the distribution profile because during create build I am getting "Provisioning profile doesn't support the Tap to Pay on iPhone capability." this should be working because I checked twice that distribution profile and certificate have this capability and added in Xcode. how can I resolve this mismatched profile issue I am using Xcode - 15.0.1

Hi everyone, We’re currently working on implementing in-app provisioning for Apple Pay, enabling users to add cards directly from within our app. We understand that Wallet Extensions are part of the expected user experience. However, we would like to know if it's acceptable to initially release the app with in-app provisioning only, and then deliver Wallet Extensions in a later update. This is mainly to manage development resources and timelines more efficiently. We want to make sure that this phased approach aligns with Apple’s expectations for app review and production usage. Has anyone followed a similar phased rollout? Any guidance or experience you can share would be greatly appreciated. Thanks in advance!