Hi, You're here because you've had issues with your implementation of In-App Provisioning Extensions for Apple Pay In-App Provisioning or In-App Verification. To prevent sending sensitive credentials in plain text, create a new report in Feedback Assistant to share the details requested below with the appropriate log profiles installed. Gathering Required Information for Troubleshooting Apple Pay In-App Provisioning or In-App Verification Issues While troubleshooting Apple Pay In-App Provisioning or In-App Verification, it is essential that the issuer is able to collect logs on their device and check those logs for error message. This is also essential when reporting issues to Apple. To gather the required data for your own debugging as well as reporting issues, please perform the following steps on the test device: Install the Apple Pay and Wallet profiles on your iOS or watchOS device. If the issue occurs on Mac, continue to Step 2. Reproduce the issue and make a note of the timestamp when the issue occurred, while optionally capturing screenshots or video. Gather a sysdiagnose on the same iOS or watchOS device, or on macOS. Create a Feedback Assistant report with the following information: The bundle IDs App bundle ID Non-UI app extension bundle ID (if applicable) UI app extension bundle ID (if applicable) The serial number of the device. For iOS and watchOS: Open Settings > General > About > Serial Number (tap and hold to copy). For macOS: Open the Apple () menu > About This Mac > Serial Number. The SEID (Secure Element Identifier) of the device, represented as a HEX encoded string. For iOS and watchOS: Open Settings > General > About > SEID (tap and hold to copy). For macOS: Open the Apple () menu > About This Mac > System Report > NVMExpress > Serial Number. The sysdiagnose gathered after reproducing the issue. The timestamp (including timezone) of when the issue was reproduced. The type of provisioning failure (e.g., error at Terms & Conditions, error when adding a card, etc.) The issuer/network/country of the provisioned card (e.g., Mastercard – US) Last 4 digits of the FPAN Last 4 digits of the DPAN (if available) Was this test initiated from the Issuer App? (e.g., yes or no) The type of environment (e.g., sandbox or production) Screenshots or videos of errors and unexpected behaviors (optional). Important: From the logs gathered above, you should be able to determine the cause of the failure from PassbookUIService, PassKit or PassKitCore, and by filtering for your SEID or bundle ID of your app or app extensions in the Console app. Submitting your feedback Before you submit to Feedback Assistant, please confirm the requested information above is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Apple Pay client. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your client, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi, To ensure the issue is not caused by an error within your app or web service request, please review the Apple Pay Merchant Integration Guide. Additionally, please review the following technotes on Apple Pay: TN3173: Troubleshooting issues with your Apple Pay merchant identifier configuration TN3174: Diagnosing issues with the Apple Pay payment sheet on your website TN3175: Diagnosing issues with displaying the Apple Pay button on your website TN3176: Troubleshooting Apple Pay payment processing issues TN3206: Updating Apple Pay certificates If the resources above don’t help identify the cause of the error, please provide more information about your app or web services to get started. To prevent sending sensitive credentials in plain text, create a report in Feedback Assistant to share the details requested below. Additionally, if the error is something we need to investigate further, the appropriate engineering teams also have access to the same information and can communicate with you directly within Feedback Assistant for more information, as needed. Please follow the instructions below to submit your report. For issues occurring with your native app or web service, perform the following steps: Install the Apple Pay profile on your iOS or watchOS device. If the issue occurs on Mac, continue to Step 2. Reproduce the issue and make a note of the timestamp when the issue occurred, while optionally capturing screenshots or video. Gather a sysdiagnose on the same iOS or watchOS device, or on macOS. Create a Feedback Assistant report with the following information: The serial number of the device. For iOS and watchOS: Open Settings > General > About > Serial Number (tap and hold to copy). For macOS: Open the Apple () menu > About This Mac > Serial Number. The SEID (Secure Element Identifier) of the device, represented as a HEX encoded string. For iOS and watchOS: open Settings > General > About > SEID (tap and hold to copy). For macOS: Open the Apple () menu > About This Mac > System Report > NVMExpress > Serial Number. The sysdiagnose gathered after reproducing the issue. The timestamp of when the issue was reproduced. Screenshots or videos of errors and unexpected behaviors (optional). Important: From the logs gathered above, you should be able to determine the cause of the failure from PassbookUIService, PassKit or PassKitCore, and by filtering for your SEID or merchant domain in the Safari Web Inspector. See Inspecting Safari on macOS to learn more. Submitting your feedback Before you submit to Feedback Assistant, please confirm the requested information above is included in your feedback. Failure to provide the requested information will only delay my investigation into the reported issue within your Apple Pay website. After your submission to Feedback Assistant is complete, please respond in your existing Developer Forums post with the Feedback ID. Once received, I can begin my investigation and determine if this issue is caused by an error within your web implementation, a configuration issue within your developer account, or an underlying system bug. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Environment macOS 26.5.1 (Build 25F80) Safari 26.5 Apple Pay JS API version 8 Using https://applepay.cdn-apple.com/jsapi/v1/apple-pay-sdk.js Reproduces on the staging website (Does not reproduce on the production website with non sandbox account) Signed into a Sandbox Tester Apple ID, with a test credit card registered exactly per Apple Pay Sandbox Testing — this is the only card in Wallet on the laptop Merchant validation is performed by our staging backend against our real (non-sandbox) merchant identity/certificate — i.e. a sandbox tester card being evaluated against a staging merchant session, which per the sandbox testing documentation is the expected/supported setup for testing on a live site without a separate merchant sandbox environment Summary After completeMerchantValidation() succeeds and the merchant session is accepted, the payment sheet still terminates with PKPaymentAuthorizationStateFatalError a few hundred milliseconds later, right after the native side logs a second "Evaluating merchant session using PROD trust policy." for the same session. The user sees "Payment failed" and the sheet closes. This happens on the very first attempt, with no user interaction beyond tapping the Apple Pay button — no shipping address is even selected before the failure. Since the sandbox tester card + production merchant session combination is the setup the sandbox testing guide describes, we'd expect the sheet to proceed to onpaymentauthorized (Apple's sandbox docs describe payments as being processed as $0 test transactions in this mode) rather than fail natively before that stage is ever reached. Steps to reproduce Visit an item page with an Apple Pay button. Tap the Apple Pay button to open the payment sheet. The sheet presents normally; no interaction with shipping address or payment method is required for the failure to occur. Within ~1 second, the sheet dismisses and displays a "Payment failed" error state. Minimal reproduction of the JS side const session = new ApplePaySession(8, { countryCode: 'US', currencyCode: 'USD', supportedNetworks: ['visa', 'masterCard', 'amex', 'discover'], merchantCapabilities: ['supports3DS'], total: { label: 'Merchant', amount: '10.00' }, }); session.onvalidatemerchant = async () => { const merchantSession = await validateMerchantOnServer(); // succeeds session.completeMerchantValidation(merchantSession); // accepted — see log below }; session.onpaymentmethodselected = () => { session.completePaymentMethodSelection({ newTotal: { label: 'Merchant', amount: '10.00' }, }); }; session.oncancel = event => console.log('cancelled', event); session.begin(); We reproduced this with both our full checkout implementation and this stripped-down request object (no shipping contact required, no line items) — same failure either way, which rules out anything about our order/line-item data. What we expected The sheet to proceed to the biometric authorization step and dispatch onpaymentauthorized once the user confirms. What actually happens The sheet fails immediately with a PKPaymentAuthorizationStateFatalError transition, even though every JS-side completion call (completeMerchantValidation, the payment-method selection) succeeded and returned PKPaymentAuthorizationStatusSuccess. System log (captured via log stream --info --debug --predicate 'process == "Safari" OR process == "passd" OR process == "com.apple.PassKit.PaymentAuthorizationUIExtension"') 21:50:41.544 PaymentCoordinator::beginPaymentSession() -> 1 21:50:41.570 Received prepareWithPaymentRequest: <private> 21:50:42.297 PaymentCoordinator::validateMerchant() 21:50:42.563 PaymentCoordinator::completeMerchantValidation() 21:50:42.564 Received merchant session update with status:PKPaymentAuthorizationStatusSuccess session:<private> 21:50:42.564 Evaluating merchant session using PROD trust policy. <- 1st occurrence, passes 21:50:42.572 PaymentCoordinator::didSelectPaymentMethod() 21:50:42.572 PaymentCoordinator::completePaymentMethodSelection() 21:50:42.653 Evaluating merchant session using PROD trust policy. <- 2nd occurrence 21:50:42.656 State machine change state from ClientCallback to PrepareTransactionDetails with param: <private> 21:50:43.391 Task Completed: <private> 21:50:43.393 State machine change state from PrepareTransactionDetails to PKPaymentAuthorizationStateFatalError with param: <private> 21:50:43.393 Error Payment failed with fatal error <private> 21:50:45.130 PaymentCoordinator::didCancelPaymentSession() The first "Evaluating merchant session using PROD trust policy." line passes (the flow continues to didSelectPaymentMethod). The second occurrence is immediately followed by Task Completed and then the FatalError transition, which suggests PassKit re-validates the merchant session's trust a second time right before PrepareTransactionDetails, and that second check is what's rejecting the session — even though the identical session object was accepted moments earlier at completeMerchantValidation(). What we've tried / ruled out Confirmed every JS completion method (completeMerchantValidation, completePaymentMethodSelection) is called and returns success — no 30-second timeout, no missing completion call, no thrown exception on our side. Reproduced with a minimal, hardcoded ApplePayPaymentRequest (fixed $10.00 total, no shipping fields) — rules out anything about our real order/line-item/sales-tax data. Reproduced on the main branch and independently on our staging deployment running unmodified code — rules out anything specific to our recent frontend changes. The <private> redaction in the system log prevents us from seeing what specifically fails during the second trust evaluation. Confirmed the sandbox tester card and its registration follow the sandbox testing guide exactly — it's the only card on the device, and no other Wallet cards are involved. Question What does PassKit's second "Evaluating merchant session using PROD trust policy" check (immediately before PrepareTransactionDetails) actually validate, beyond what's already checked at completeMerchantValidation() time? Is a sandbox tester card being evaluated against a production merchant session expected to pass this second check, or does sandbox testing per the linked guide require something additional on the merchant/session side (e.g. a specific field on the merchant session, or a specific environment value) that our backend isn't setting? Is there a way to get an unredacted reason for the rejection — e.g. via a private-data-enabled log profile or another diagnostic — since the redacted system log alone doesn't surface one?

I'm on a 16" MacBook Pro M4 Max w/ 36 GB RAM Apple Pay had been working with the beta releases with not issues, but after the macOS 26.6 beta update, Apple Pay was deactivated and is showing an error message: Apple Pay has been disabled because the security settings of this Mac were modified I found suggested fixes on the non-beta Apple forums (since this issue has apparently struck past release-versions of macOS), but none of them have worked. Does anyone here have any notions? Thanks!

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

Hello everyone, We are experiencing an issue with our Apple Pay integration on a Magento 2 store using the Rootways Authorize.net module. Standard Credit Card and Google Pay transactions are processing without issue, but Apple Pay transactions are failing immediately after user authentication. Issue Description The Apple Pay payment sheet opens correctly, and the customer is prompted for biometric verification. Immediately after completing the biometric verification, the UI spins briefly and then states that the payment failed. Technical Details & Console Logs Reviewing the browser developer console during the failure reveals the following sequence: Merchant Validation Success: The rw_onvalidatemerchant function executes successfully. The promise returns as "fulfilled" and generates the proper payload, including the merchantSessionIdentifier, nonce, and signature for our domain (2b5eae029c.nxcli.io). Cancel Event Triggered: Shortly after successful validation, an ApplePayCancelEvent is thrown while a promise is still "pending". Unknown Session Error: Within this cancel event, the sessionError returns a code of "unknown" with an empty info: {} object. Context Error: We are also seeing a strict mode JavaScript error in the object prototype reading: TypeError: 'arguments', 'callee', and 'caller' cannot be accessed in this context. Environment details: Platform: Magento 2 Payment Module: Rootways Authorize.net Domain: 2b5eae029c.nxcli.io Has anyone encountered this specific sequence of events or seen this strict mode JS error trigger an ApplePayCancelEvent? Any guidance on why the session triggers a cancel event post-verification—or suggestions on how to further debug this "unknown" session error—would be greatly appreciated. Thank you!

I am seeing a reproducible Apple Pay card provisioning failure on iOS 27 Beta 6 (24A5418b). The card eligibility check succeeds and the Apple Pay provisioning response contains a valid termsID, but provisioning subsequently enters the Secure Element storage-management stage and fails with: SEStorageManagementSheet Code 4 SES.presentationTimedOut The Terms & Conditions screen therefore never appears and provisioning cannot continue. I reproduced the same system-level failure through multiple independent provisioning paths: First-party Apple Wallet provisioning with manual card entry Wallet-initiated provisioning that redirects to the issuer app Issuer-app initiated in-app provisioning The issue affects multiple issuers, including East West Bank and Mercury. The same iPhone successfully provisioned Chase UK and HSBC Hong Kong cards on an earlier iOS 27 beta build, and Apple Pay provisioning worked normally on iOS 26. I have already tested different network conditions, reset network settings, and removed two existing Apple Pay cards before reproduction. The behavior remains unchanged. Two separate sysdiagnoses show the same failure path. During the latest reproduction, SESUIServiceApp was successfully launched, but provisioning ultimately failed during SEStorageManagementSheet presentation with SES.presentationTimedOut. The captured RunningBoard state also showed SESUIServiceApp in a background/suspended state rather than maintaining a successful remote presentation. I have submitted the complete diagnostics and sysdiagnose files through Feedback Assistant: FB24403156 Could an Apple Wallet / Apple Pay engineer please review this Feedback and investigate the SESUIServiceApp / SEStorageManagementSheet remote presentation path on iOS 27? For privacy reasons, I am not attaching the full sysdiagnose publicly here; the diagnostic files are attached to FB24403156

Hello. We are an acquirer and we have timeouts in about 7-8% of requests to https://apple-pay-gateway.apple.com/paymentservices/paymentSession in the last 30 minutes since 07:00 EET. Our timeout is 60 seconds. We've checked and don't see any issues on our side. There were no changes in our infrastructure setup.

We manage provisioning for a large number of App IDs across multiple apps via CI, using the App Store Connect API (not session-based Spaceship/Xcode auth). Capability management works well end to end for everything we've tried — Push Notifications, App Groups, Associated Domains, Data Protection, etc. can all be created, updated, and deleted via POST/PATCH/DELETE on /v1/bundleIdCapabilities. Apple Pay is the one exception. We can enable the Apple Pay capability itself via the API the same way as anything else, but there's no way to associate that capability with a specific Merchant ID. /v1/merchantIds exists as its own resource, but nothing in the bundleIdCapabilities or bundleIds schema links to it — no relationship, no include, no dedicated endpoint. In practice this means every new Apple Pay-enabled App ID we provision needs someone to go into the Developer Portal by hand (Identifiers → App ID → Capabilities → Apple Pay → select Merchant ID) before the generated provisioning profile will actually build — otherwise Xcode fails with errors like "doesn't include the Apple Pay capability" / "doesn't support the Merchant ID". Every other capability we use is fully scriptable; this is the one manual step left in an otherwise automated pipeline. Has anyone found a documented (or undocumented) way to do this via the API? If this is a confirmed gap rather than something we're missing, I've filed it as FB24414090 — if you've hit the same thing, adding your own Feedback number to a report on the same gap seems to be one of the few things that actually helps get traction internally, so feel free to reference this thread if you file one too.

Our issuer app's in-app provisioning fails at ProvisioningStepEligibility with PKPaymentWebServiceErrorDomain Code=40001 "Invalid Card - Check the information on your card and try again." (HTTP 403), before Terms & Conditions are presented. Setup: Mastercard/US, PNO Payment Data Configuration 3 (Encrypted FPAN), EV_ECC_V2, TestFlight build, initiated from the issuer app. The certificate fetch (issuerProvisioningCertificates?encryptionVersion=EV_ECC_v2) returns 200, the ephemeral public key is uncompressed 65 bytes with a leading 0x04, and the Configuration 3 payload contains all eight required keys with correctly hex-encoded nonce and nonceSignature. Since the request reaches the eligibility step and returns a card-level error rather than a cryptography error, the rejection appears to be on the card data itself rather than the envelope. Filed with sysdiagnose, timestamps, and full correlation identifiers as FB24418152. We would appreciate help determining whether errorCode 40001 originates from Apple's validation of the decrypted payload or is relayed from the PNO, and if Apple decrypted it, which field failed validation. Thank you

Hi everyone, I am stuck in a serious account provisioning/sync loop and need some advice or visibility from Apple moderators. The Issue: I purchased and completed the $99 Apple Developer Program subscription directly through the official Apple Developer app on iOS. The charge is fully processed, and the subscription shows as active under my Apple ID subscriptions and bank account. However, when I log into developer.apple.com with the exact same Apple ID, the portal completely ignores my active membership and redirects me to the "Become a member / Start your enrollment" page. Because the web backend doesn't recognize my active subscription, App Store Connect loads a completely blank/white screen on web browsers, and the App Store Connect iOS app throws Error 2002 (Developer Account Required). What I've tried: Double-checked that I am logged into the exact same email/Apple ID across all platforms. Cleared all browser cache, cookies, and tried Incognito/Private mode on multiple browsers (Safari & Chrome) and different devices. Tried waiting out the 48-hour sync window, but the system is completely disconnected. It seems like a critical backend synchronization bug where the App Store subscription ledger failed to update my developer team portal profile status to Active. Has anyone found a way to trigger the sync manually, or do I have to wait for senior developer relations support to do a manual override? Any help or advice would be greatly appreciated. its been 4 days ago and nothing

Hi everyone, I'm trying to add a Canadian bank account to App Store Connect so that payments from Apple can be deposited into the account. The bank account is with TD Canada Trust. The correct Canadian banking information is: Bank: TD Canada Trust Institution Number: 004 Transit Number: 05470 Expected routing number: 054700004 However, when I enter the transit number in App Store Connect, the system automatically changes the value and displays: 054700018 It also identifies the bank as Mennonite Trust. It appears that App Store Connect is interpreting the transit number as belonging to institution 018, whereas my actual bank is TD with institution 004. I've tried entering the information again, but the value is automatically populated/overridden, so I can't enter the correct routing information. Has anyone encountered this issue when adding a Canadian bank account to App Store Connect? If so: Were you able to resolve it? Is there a particular format I should use for the transit number? Does Apple need to manually correct the bank/branch mapping? Is there another way to add the TD account? I've attached a screenshot showing the incorrect value being populated by App Store Connect. Any help would be greatly appreciated. Thank you!

We are implementing In-App Provisioning functionality for our Bank but there is always 500 Internal Server Error respond by Apple server once we tried to add card to apple wallet. Our code let request = PKAddPaymentPassRequest() request.activationData = try decodeBase64(payload.activationDataText, field: "activationDataText") request.encryptedPassData = try decodeBase64(payload.encryptedDataText, field: "encryptedDataText") request.ephemeralPublicKey = try decodeBase64(payload.ephemeralPublicKeyText, field: "ephemeralPublicKeyText") return request Because of fPanId is not required so we are not pass it to Apple server and that field generated once the card already added to wallet. Please help us investigate the issue, thanks! FeedbackId 24065847 (In-App Provisioning 500 Internel Error)

We are implementing In-App Provisioning functionality for our Bank but there is always 500 Internal Server Error respond by Apple server once we tried to add card to apple wallet. Our code let request = PKAddPaymentPassRequest() request.activationData = try decodeBase64(payload.activationDataText, field: "activationDataText") request.encryptedPassData = try decodeBase64(payload.encryptedDataText, field: "encryptedDataText") request.ephemeralPublicKey = try decodeBase64(payload.ephemeralPublicKeyText, field: "ephemeralPublicKeyText") return request Because of fPanId is not required so we are not pass it to Apple server and that field generated once the card already added to wallet. Please help us investigate the issue, thanks! FeedbackId 24065847 (In-App Provisioning 500 Internel Error)

Hello, We are implementing in-app provisioning in our banking app but are having trouble getting to the Terms & Conditions screen. User taps on “Add to Apple Wallet” > PKAddPaymentPassViewController > Next > the flow fails quickly with "Could Not Add Card -> Set Up Later" alert. The only notable thing in the logs, as far as I can see is the https://nc-pod12-smp-device.apple.com:443/broker/v4/devices/{SEID}/cards fails with: <html> <head><title>500 Internal Server Error</title></head> <body> <center><h1>500 Internal Server Error</h1></center> <hr><center>Apple</center> </body> </html> and maybe ProvisioningOperationComposer: Step 'eligibility' failed with error <PKProvisioningError: severity: 'terminal'; internalDebugDescriptions: '( "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; > Feedback Assistant ID: FB22932141 (Error during In-App Provisioning)

Hi! We recently signed up and activated the Web Merchant Registration API and registered a few of our merchants. We registered them as: { "domainNames" : ["X"], "partnerMerchantName" : "Name", "partnerInternalMerchantIdentifier": "MID-###", "encryptTo" : "platformintegrator.X", "merchantUrl": "https://www.x" } When we make the payment with startsession, we are getting an error 400: Payment Services Exception merchantId=platformintegrator.x not registered for domain=x I suspect that this has to do with the value of merchantIdentifier we are setting in the startsession. What should it be? MID-###? The encryptTo hash of platform? platformintegrator.x? Also, what's the meaning of the property on the sub-merchant I get from the GET API call delegatedCommerce: {enabled=True}?

We are currently supporting an Apple Pay-enabled card program as an issuer/issuer processor and have successfully completed In-App Push Provisioning integration within our iOS application. The in-app flow is fully operational, including issuer-side cryptographic exchange and Mastercard MDES network tokenization. We are now looking to extend this integration to support Apple Pay Web Push Provisioning, allowing cardholders to add eligible cards to Apple Wallet directly from our web application. We would appreciate guidance on: -The process for enrolling in Apple Business Register (if required) -Enabling Web Push Provisioning for an issuer profile Required entitlements or provisioning certificates Any additional onboarding steps specific to issuer-level Web provisioning We understand that Web Push Provisioning requires issuer-level enablement beyond standard Apple Pay on the Web, and we would like clarification on the correct path to activate this capability. Thank you in advance for your guidance.

We are implementing in-app provisioning in our fintech app; We are reaching out to ask for your help in understanding what is going wrong so we can fix it. What happens: User taps “Add to Apple Wallet” → we present PKAddPaymentPassViewController → they tap Next → after a few seconds the flow fails with "Set Up Later" alert. Device log: "eligibility request failure", "Received HTTP 500" )'; underlyingError: 'Error Domain=PKPaymentWebServiceErrorDomain Code=0 "Unexpected error." UserInfo={PKErrorHTTPResponseStatusCodeKey=500, NSLocalizedDescription=Unexpected error.}'; userInfo: '{ PKErrorHTTPResponseStatusCodeKey = 500; }'; > Feedback Assistant ID: FB22176928 (In-App Provisioning issue 500 Internal Server Error)

Hi everyone, We recently renewed and successfully paid for our Apple Developer Program membership. However, our account is still showing as expired, and we're unable to access the developer services that require an active membership. We've already completed the payment, but the membership status has not updated yet. Has anyone experienced this issue before? How long did it take for your membership to become active after payment? Is there anything we need to do, or is this just a delay on Apple's side? Should we contact Apple Developer Support, or will the status update automatically? Any advice would be greatly appreciated. Thank you!

Hello, We are trying to provision in apple wallet, I am getting an error "Card can not be added". Please check below and let me know if I am missing anything. SEID: 04401D7BCE578001930001236930311377D86C15D956BBA1 TimeStamp: 2025-08-18 11:53:04.570431-0500. CST Last 4 FPAN: 2345 Thanks

Waiting on in-app provisioning approval. First time submitting the app. The process changed after we submitted initially but its been three months now. Every time I reach out I either get a generic response or nothing at all. What is going on? This has been a horrible experience.

We had noticed “paymentCredentialsAvailable” is getting returned more from apple pay capabilities for some unexpected devices (our example is windows + chrome). Based off the documentation this should only be returning if this is linked to a wallet account w/ valid payment. From some investigation this appears to have changed from apple pay js v1.3.7 to v1.3.8 (latest). Previously the above windows + chrome example would return “paymentCredentialStatusUnknown” which is what would be expected in this case. Tried running chrome in icognito mode and clearing cookies just in case this check had some linkage to the apple account via QR code usage, but did not appear to affect the returned response. Unsure if this is a bug or a change to the logic, but doesn’t appear to be appropriately reflected in the documentation, also a change like this should not be appearing in a patch version. Has anyone else experienced this?