I'm implementing Wallet order tracking for a shop and have run into an update problem that I haven't been able to explain. This is the Wallet Orders web service and signed .order packages, not .pkpass passes or orders found in Mail. I've filed FB25380857 with a detailed timeline and a redacted sender example. I'm posting here because I would also like someone to check whether there's a mistake or unsupported assumption in our integration. If there is a parameter or response we should change, I'd much rather find it now than blame the OS. The short version: the phone receives our APNs message almost immediately, but sometimes doesn't ask our server for the updated order for hours. Once it finally makes the request, the package downloads, applies and produces the expected notification normally. How the service is set up Orders are added from Safari using the Wallet button. There is no separate native app. Registration succeeds, and the phone initially downloads and displays the order. We send to the production APNs endpoint over HTTP/2, using the Order Type certificate and key. The topic matches the Order Type ID. The request body is exactly {}. Our normal sender leaves the priority at its default of 10, and for the tests below I explicitly set it to 10. The push-type header is omitted. TLS verification is enabled, and apns-expiration is set to the current time plus one hour. The effective request is: POST https://api.push.apple.com/3/device/<registeredPushToken> apns-topic: <orderTypeIdentifier> apns-priority: 10 apns-expiration: <currentEpochPlus3600> content-type: application/json {}Each update keeps the same order ID, authentication token, webServiceURL and createdAt. updatedAt is an RFC 3339 timestamp and strictly increases. The device registration endpoint returns 201/200. The changed-orders endpoint returns lastModified and the registered orderIdentifiers, or 204 if nothing has changed. The package endpoint returns the signed .order with the finance.order MIME type, Last-Modified and conditional 304 support. The changed-orders response is no-store, and the package response is private, max-age=0, must-revalidate. One detail I'm unsure about: our isolated test orders share one Order Type ID, but each test has its own stable webServiceURL. Is that supported, or should all orders under an Order Type use the same service URL? The affected phone's diagnostic build is 24B119, listed in Feedback Assistant as iOS 27.2. The Wallet logging profile was already installed before these tests, and the phone had been restarted. These are synthetic orders, with no real purchase or carrier operation. The longest delay we captured Times below are local, Europe/Budapest, UTC+01:00, on October 30–31, 2026. October 30, 18:43:56: the screen is off. 18:44:16: we change the order from ready for pickup to picked up/completed and send the update signal. APNs returns 200. 18:44:16.903: apsd receives the message. At .905, financed logs receipt in both its Push and Orders handlers for our exact Order Type. No immediate Orders task or changed-orders request follows. Normal confirmation retries go out at 18:55:02 and 19:05:02. October 31, 10:53:22–23: Wallet enters the foreground and becomes active. 10:53:25.884: pending Orders work starts. 10:53:26: the phone asks for changed orders and downloads the pending package with HTTP 200. 10:53:27: the phone logs that it applies the update and schedules the notification. The picked-up notification appears. That is 16 hours, 9 minutes from the first signal to the package response. There was no new signal from our server that morning. I had opened Wallet, but did not deliberately pull to refresh; I can't completely rule out an accidental gesture. I therefore don't want to claim that opening Wallet alone is a reliable workaround. We have also captured a shipping update that took about 41 minutes, and another completion update that took almost two hours despite the phone being locked before the send. In that second case, the logs show a previously scheduled Orders task running just before the successful fetch, rather than a new push arriving then. An explicit manual pull can fetch the same pending package promptly. For comparison, a new order on another iPhone made its changed-orders request and downloaded an update within three seconds. We have not yet confirmed the visible result on that phone, and it was only a processing-description change, so it isn't an equivalent fulfillment-notification test. We tried explicit priority 10, an alert push-type control, and one background/priority-5 control. They did not produce an immediate fetch in the captured windows. A separate content-available payload experiment also reached the handler without starting a fetch; that is not our normal payload and hasn't been deployed as a fix. The full report keeps these controls and normal retries separate. What I'd like to understand Is the APNs request above correct for Wallet Orders? Are we missing a required header, payload detail or registration step? Could the shared Order Type with different webServiceURLs cause this, even though the same order updates successfully after a manual pull or later task? Is there a supported way to recover when a received update signal leaves the changed-orders request pending for hours? What conditions should we check before sending more signals or asking users to re-add an order? What further diagnostic would be useful? We have retained the original phone's sysdiagnose and separate log archives for these events and can provide them privately through the Feedback report. A 15–30 minute delay would be acceptable for our parcel-status use case. An order still showing ready for pickup the next morning is a different problem. I'm not suggesting Apple promises a particular delivery time; I'm trying to find out whether we can make this integration reasonably dependable, and what we need to correct on our side. No keys, device/push tokens, customer information or full device logs are included in this post.

Im trying to implement add to Apple Pay feature in my app. I have an issuer bank's credit card as an existing feature. Now question is, say its added successfully already, I relaunch my app, how to tell if already added to Apple Pay? I have made some reads, and asked AIs, but I can't seem to get a clear answer. Passkit's primaryAccountIdentifier - if use this, how will our backend store this? I mean, I don't think its ideal approach for mobile app to be responsible for calling backend api. deviceAccountNumberSuffix - what if my app have other cards that can be added to Apple Pay and has same suffix. Then seems broken flow.

We are unable to verify our Apple Pay merchant domains. Apple Developer Portal returns: “Domain verification failed. Review your TLS Certificate configuration to confirm that the certificate is accessible and a supported TLS Cipher Suite is used.” We have confirmed that the verification endpoints are publicly accessible, return HTTP 200, and support TLS 1.2/1.3 with valid certificates and supported cipher suites. The domains are behind Cloudflare. However, when verification is triggered, we do not see an HTTP request from Apple in our Cloudflare request logs. Has anyone experienced a similar issue with Apple Pay merchant domain verification, especially with domains behind Cloudflare? We have also submitted a report through Feedback Assistant.

We are an acquirer/payment provider offering Apple Pay. Our merchants use our hosted checkout to accept payments. After a user pays with Apple Pay on our checkout, the Wallet transaction record shows our checkout domain as the payee. We would like it to display the merchant’s brand/name so users can recognize or contact the merchant. Is there any parameter or configuration that controls what Wallet shows as the payee? For example, can this be set via a specific field/parameter, or is it strictly derived from the Merchant ID’s display name (or other Apple Pay configuration)? What is the correct approach for a PSP/acquirer to have the merchant’s brand shown in Wallet transaction record? Additional detail: The field in question is the merchant/payee name shown in the Apple Wallet receipt—directly under the transaction amount at the top of the receipt, and again beneath the “Total” line.

We are a Payment Service Provider (PSP)/Payment Processor/Payment Gateway and have completed the Apple Pay integration and successfully tested transactions in the Sandbox environment. We are now planning to move the integration to Production and would like to understand the prerequisites, certification requirements and process involved in enabling Apple Pay for our merchants. Could you please clarify the following: Production Enablement: What are the mandatory prerequisites for a PSP/Payment Processor/Payment Gateway to move from Sandbox to Production? Certification: Is formal certification or approval from Apple required for the Payment Processor before Go-Live? Certificates: Are separate Production Payment Processing and Merchant Identity Certificates required? Merchant Onboarding: What is the process for onboarding and enabling individual merchants under our PSP/Payment Processor setup? Any provisions for Bulk On-boarding? Testing & Validation: Are there any mandatory test scenarios or validations required before Production enablement? Production Access: What approvals, configurations or access enablements are required from Apple's end? Go-Live Process: What is the recommended sequence of activities and expected timeline for Production activation?

Hello Apple Developer Community, We're developing an iOS application using React Native (Expo) with a Node.js backend. We have already integrated Apple's In-App Purchase (IAP) system for subscriptions and digital features. However, we're also considering integrating Stripe as an additional payment method, while continuing to support Apple IAP. We recently came across Stripe's official iOS SDK documentation: https://docs.stripe.com/sdks/ios We would appreciate clarification on the following questions: Does Apple permit developers to integrate Stripe alongside Apple IAP within the same iOS application? Can users be offered both Stripe and Apple IAP as payment options for the same digital subscriptions or in-app features? Are there specific App Store Review Guidelines governing the use of third-party payment providers alongside Apple IAP? Do the requirements differ depending on the user's country or App Store region? If Stripe is integrated as an additional payment option, are there specific entitlements, disclosures, or approval processes required to comply with Apple's policies? Could offering both payment methods affect the App Store review or approval process, even if Apple IAP remains fully functional? Our intention is not to replace or bypass Apple IAP. We simply want to understand whether Stripe can be offered as an additional payment option while remaining fully compliant with Apple's App Store Review Guidelines. We would appreciate any official guidance, relevant documentation, or insights from developers who have successfully implemented both payment systems. Thank you for your time and assistance.

We are an acquirer and PSP and we are building our Apple Pay on the Web integration, starting in India. Please tell us what is needed to enable merchants in other countries like Singapore, Hongkong, New Zealand, etc. Does one Platform Integrator ID and one set of certificates cover merchants in all countries? Which country code should the payment request carry for a merchant whose acquirer processes in a different country? Are there per-country requirements for networks, currencies or issuer participation that affect acceptance? Is there a published list of countries where the Registration API model is supported? Is any separate onboarding with Apple required per country?

We are an acquirer and PSP with our own payment gateway. Merchants can either: Use an Apple Pay payment page hosted by us, or Host their own payment page and submit payment data to us via server-to-server APIs. We are currently implementing Apple Pay on the Web using the Platform Integrator model. The acquirer-hosted payment page flow is clear to us, but we have a few questions regarding merchant-hosted payment pages. Our current understanding (please correct us if any of this is incorrect) We register each merchant using the Web Merchant Registration API as a Platform Integrator, with a unique partnerInternalMerchantIdentifier. Merchants do not have their own Apple Developer accounts. For merchant-hosted payment pages, the merchant's checkout domain is provided in domainNames. The domain verification file is downloaded from our Apple Developer account (Platform Integrator account), and the merchant hosts that file under the /.well-known/ path on their domain. The merchant registration created through the Web Merchant Registration API is then used for Apple Pay eligibility checks and merchant validation. Questions: Domain registration For a merchant-hosted payment page, is it correct to register the merchant's domain against that merchant's partnerInternalMerchantIdentifier registration? Verification file When onboarding multiple merchants: Is the same domain association file used across all merchant domains? Or is a unique verification file generated per merchant registration? Eligibility checks and Apple Pay button The "Supporting Apple Pay on Third-Party Browsers" documentation (Scenario 3) suggests that a payment service provider may provide a JavaScript library that loads apple-pay-sdk.js for merchants. For merchant-hosted pages, is it supported and recommended for the PSP/platform integrator to provide a thin wrapper library around: canMakePayments() applePayCapabilities() Apple Pay button rendering Session creation Or is Apple’s preferred approach that the merchant's checkout page interacts directly with Apple Pay JS APIs? PSP/acquirer decrypts the payment token If the PSP/acquirer is responsible for token decryption, we understand that encryptTo should be set to the Platform Integrator identifier. For merchant-hosted payment pages, are there any additional requirements beyond domain registration and merchant validation? Merchant decrypts the payment token We would also like to support a model where the merchant decrypts Apple Pay tokens directly. In that case, our understanding is that encryptTo must reference the merchant's identifier rather than the Platform Integrator identifier. Is that understanding correct, and are there any additional onboarding or registration requirements for that model? Merchant validation For merchant-hosted checkout pages, what is the expected implementation pattern for onvalidatemerchant? Specifically: Should the merchant's frontend send the validationURL to the PSP/platform integrator backend, which then performs merchant validation with Apple and returns the merchant session? Or is a different flow expected when using the Platform Integrator model? Any clarification or guidance would be greatly appreciated. Thank you.

Our payment processor can't decrypt the Apple Pay payment tokens for some of our recurring payment (continuous payment authority) set-ups. These are Apple Pay on the Web payments where the request includes a recurringPaymentRequest, to set up the agreement without taking a payment. Our payment processor says the decryption fails on their side before the payment is authorised, and they asked us to raise it with Apple. Our one-off Apple Pay payments with the same merchant ID decrypt normally as do a number of our recurring payments. We have reviewed the decryption errors section of troubleshooting-apple-pay-payment-processing-issues and haven't found a cause that explains why only the recurring set-ups fail. We have the transaction identifiers and timestamps for the affected payments, and we can share them privately. Could you confirm whether these tokens were encrypted with our merchant's payment processing certificate, and whether recurring or merchant-token set-ups are handled differently? The code-level support form asked us to post here first because we don't have an Xcode project. If Feedback Assistant would be better for this, we're happy to file a report there and reply with the Feedback ID. Thank you

My account page shows my name with (Pending) and the message: "Purchase your membership. To continue your enrollment, complete your purchase now. Your purchase may take up to 48 hours to process." Every payment attempt is declined at checkout. What I have checked Apple Account: legal name, date of birth (over 18), country/region Türkiye and two-factor authentication are all set and correct. I signed the Apple Developer Agreement on October 11, 2026. Cards tried: more than 10 different cards (Visa and Mastercard, debit and credit) from several Turkish issuers, including Ziraat Bankası and Papara. All are in my own name and enabled for online and international payments. Every one of them was declined the same way. Billing address matches my bank records exactly. No VPN was used, and I tried with a normal browser window. The payment request never reaches the card issuers. My bank and Papara both confirm there is no authorization attempt, declined or otherwise, on their side. The decline seems to happen before the issuer is contacted. One of these cards was added successfully as a payment method to my Apple Account, so Apple accepts the card in general. More than 10 cards from different banks all fail in exactly the same way, and none of the requests reach the issuers. So I believe the block is on Apple's side rather than with any specific card or bank. Timeline Oct 11: Signed the Apple Developer Agreement and started enrollment on the web. Oct 16 – 17: Repeated payment failures on the web. I contacted Apple Developer Program Support on Oct 17 (Case ID: 102999572212) and haven't received a reply yet. I don't own an iPhone, so I tried the Apple Developer app on a friend's iPhone. To do that I withdrew my web enrollment (it was withdrawn on Oct 16 and Oct 17), but enrollment in the app was still unavailable. Oct 18: I started the enrollment again on the web. It's back at "Purchase your membership", and payment still fails. My questions Is there a known issue with Developer Program payments from Türkiye, or a restriction on my account that blocks the payment before it reaches the bank? Can Apple complete the membership purchase manually, for example by charging the card already saved on my Apple Account, or by sending a payment link? Could Apple staff please check my case (102999572212)? I can provide my Enrollment ID privately. If anyone in Türkiye has solved this (a specific card type or bank, a billing address format, or a phone call with support), I'd be grateful if you shared what worked. Thank you!

Hello, I'm trying to enroll in the Apple Developer Program as an individual from Türkiye. My enrollment status currently shows "Pending", and the website asks me to complete my membership purchase. However, whenever I try to pay, I receive the error "Payment Authorization Failed". I've tried different payment cards, but the issue persists. I also tried the Apple Developer app on an iPhone, but the "Enroll Now" button is greyed out and cannot be selected. Has anyone experienced this issue? How can I resolve the payment problem or enable enrollment through the app? Thank you!

im developing apple pay in safari and im using iPhone 15 & ios version 26.5 to test. im testing the scenario, when user is logged off apple account and try apple pay, there should be a pop up message, giving user two options: Cancel & Sign In. when im testing on mac, the pop up window works fine with title 'Apple Pay requires icloud' - Sign in your apple account to set up apple pay - cancel & sign in however, when im testing on my iphone, the pop up window vanish very quickly in like 1 second. im wondering how to fix the issue so that user can be redirect to sign in their account.

Hello Apple Developer Support, I am the owner of LUXARION LLC. I paid the $99 Apple Developer Program membership fee on October 2, 2026, but my organization enrollment is still showing as Pending as of October 13, 2026. I have contacted Apple Developer Support multiple times and opened a new support case, but I have not received a response or a resolution. My enrollment has now been pending for 11 days, and I am unable to proceed with publishing my app. Phone support is not available in my region, so I am seeking assistance through this forum. Could an Apple Developer Support representative please review my enrollment and help determine why my membership has not been activated despite payment? I can provide my enrollment details, order confirmation, and support case numbers privately through the official support channel. Thank you.

Does anyone know how to implement Apple Account Binding for Wallet Pass function like https://www.ticketswest.com/customer-service/nfc-apple-account-binding/apple-account-bin

Apple Pay for Partners brings together the latest news, features, and fraud protection information for issuers, merchants, and platforms — all designed to support your integration and help you deliver the payment experience customers know and trust. Available in English only. Explore Apple Pay for Partners >

I am working on In-App-Verification. I am able to add my cards manually in the Apple Wallet Sandbox. I am getting the option to Verify using App. When I click on the Verify Button, I am able to redirect to my Testflight App. But when I use the API PKPassLibrary().pass(withPassTypeIdentifier: passTypeIdentifier, serialNumber: serialNumber) its not returning me the expected Pass. It is infact giving an empty result The entitlements which I already have added are: com.apple.developer.pass-type-identifiers com.apple.developer.payment-pass-provisioning So I have below questions: Do I need to do something else for PassKit API's to work? Is it even possible to test In-App-Verification in the TestFlight App using sandbox Wallet? Is it possible to redirect user to debug and enterprise builds also as currently the redirection from Apple Wallet is not working for debug and enterprise builds? The PassKit API which I indicated earlier is working in debug build when I sideload from Xcode. But since deeplink from Wallet does not work for debug builds, I am not able to proceed with testing. What will be behavior in App-Store build production environment without using sandbox, by using real cards? Will it work there?

I am working on In-App-Verification. I am able to add my cards manually in the Apple Wallet Sandbox. I am getting the option to Verify using App. When I click on the Verify Button, I am able to redirect to my Testflight App. But when I use the API PKPassLibrary().pass(withPassTypeIdentifier: passTypeIdentifier, serialNumber: serialNumber) its not returning me the expected Pass. It is in-fact giving an empty result So I have below questions: Do I need to do something else for PassKit API's to work? Is it even possible to test In-App-Verification in the TestFlight App using sandbox Wallet?

I am a PSP for Apple Pay, and I have been experiencing timeouts while registering a domain for my merchant. What configurations should my merchant make?

Hi, We recently applied for the Web Merchant Registration API and created our platform integrator ID. I am trying to register a domain in sandbox with the API: POST https://apple-pay-gateway-cert.apple.com/paymentservices/registerMerchant Content-Type: application/json { "domainNames": ["<URL>"], "partnerInternalMerchantIdentifier": "<merchant_id>", "partnerMerchantName": "<merchant_name>", "encryptTo": "<platform_integrator_id>" } Client certificate is provided via curl --cert/--key; the TLS 1.3 handshake completes successfully — the server requests the client cert, our Certificate + CERT verify are accepted, and the connection is established. But the response is { "statusMessage": "Payment Services Exception Unauthorized", "statusCode": "401" } How do I go about debugging this?

We test Apple Pay in the sandbox on supervised iPhones in a device lab (Apple Configurator supervision, no MDM enrollment, no SIM, iOS 26.x). Since late September two of the test cards from the Sandbox Testing page no longer add to Wallet. Discover test cards still add fine on the same devices and accounts. Filed as FB24994276 (Visa) and FB24994258 (Mastercard), with device logs and timestamps. Visa 4622 9431 2318 9285 (FB24994276), only on our lab devices: eligibility → 412 → TSM sync → 200, "received eligibility status: 1" terms shown and accepted provision → HTTP 403 → PKProvisioningErrorDomain Code=3 → "Invalid Card" Same result on two different lab iPhones, including one signed in to a brand-new sandbox account. The same new account and the same card add successfully on an unsupervised iPhone on a home network (iOS 18.2.1). Neither side sends location data. Mastercard 5204 2452 5046 0049 (FB24994258), on every device we tried, lab and home, iOS 18.2.1 and 26.x: eligibility → 412 → TSM sync → retry → HTTP 500 → PKProvisioningErrorDomain Code=5 Questions: What does the 403 at the provisioning step mean for the Visa card? Does supervision, the iOS version, our network egress, or the fact that our devices re-provision cards every test session play a role? Is the Mastercard sandbox environment currently broken, or is there a Mastercard test card that works? Happy to capture a sysdiagnose with the Wallet logging profile if that helps.