“sandbox”

Hi @Gijunius, You wrote: [...] Is it possible to suppress Express Mode behavior (similar to requestAutomaticPassPresentationSuppression) even when the app is launched via a widget interaction [...] Alternatively, is there any way to delay or defer Express Mode activation temporarily when launching from a widget or during BLE communication? [...] No, Express Mode can't be suppressed programmatically, regardless of whether the app is launched from a widget or directly. This is a fundamental distribution from the Automatic Pass Presentation Suppression behavior. The requestAutomaticPassPresentationSuppression(reason:) API only suppresses the Wallet UI from appearing when an NFC field is detected. It doesn't suppress Express Mode transactions because: Express Mode operates at the Secure Element/NFC controller live, below the operating system. The transaction completes in hardware without any OS or app involvement. This is by design for reliability (transit gates have sub-second timing requirements). That said, ev

Hi @wehtam, You wrote: [...] However, when I place my finger on the Touch ID, I get a payment error. This issue only occurs in production mode. In sandbox mode, everything works perfectly. [...] Here is a log file: [...] Thanks for the log file. The failure happens at the Rewrap phase, confirmed by these three consecutive log lines: Response: 500 Time profile: 0.444229 seconds { 10 fields } 117 bytes Web service error without a retry nonce. Failing payment State machine change state from PKPaymentAuthorizationStateRewrap to PKPaymentAuthorizationStateFatalError After the Touch ID succeeds and the Secure Element generates the payment cryptogram, Apple's SMP (Secure Element Management Protocol) server takes that cryptogram and encrypts it using your merchant's production Payment Processing Certificate (PPC) public key. This rewrapped token is what gets sent to your payment processor. The 500 error is coming from the Apple Pay servers during this step — meaning Apple attempted to rewrap the cryptogram u

Hi @TBAbnxxm1337, You wrote: [...] is it possible to update certificates on the master account without changing the keystores and certificate identities? The short answer is: No — not fully. But downtime can be completely avoided with the right approach. Regardless of the solution, keystones must change. Apple's certificate issuance always requires a new CSR, which means a new key pair is generated. The private key changes on every renewal — there is no mechanism in Apple's PKI to re-sign an existing key. Since the private key is different, any keystore or .p12 bundle that contains both the certificate and the private key must also be updated. There is a minor bit of relief if your clients load the certificate and private key as separate files (e.g., merchant_id.pem and privkey.key independently), you can reuse the existing private key by generating the new CSR from it: # Generate a new CSR from your EXISTING private key openssl req -new -key privkey.key # <-- same key, no change to this file -out renewa

Hi @fl1, You wrote: We are experiencing intermittent 403 Forbidden errors during Apple Pay on web merchant validation in our production and sandbox environment. [...] During this time, the intermittent 403s could very well be attributed to Apple's phased TLS 1.3 enforcement rollout combined with the intermediate CA rotation — different merchants were affected at different times depending on which gateway nodes serve their region. Pair that with a hardcoded validationURL hostname allowlist and you have the recipe for the exact intermittent pattern you've described. However, if anyone else experiences this behavior currently, I want to provide some debugging tips: A 403 on the server-to-Apple hops is nearly always a certificate, domain, or request-body problem. A 403 on the browser-to-your-server hop is your own auth/CORS issue. Start your investigation by validating your certificate chain: # Validate your certificate chain end-to-end openssl verify -CAfile AppleRootCA-G3.cer -untrusted apple-intermedi

Hi @Remya Shan, You wrote: [...] We have created a tester account as India country. Is that an issue? Yes. India is not a supported country or region for Apple Pay. To resolve this, use a supported country for your Sandbox Tester Account, such as Germany, United Kingdom, Switzerland (relevant for Saferpay and Worldline), and United States. Cheers, Paris X Pinkney |  WWDR | DTS Engineer

Hi @GSadee, You wrote: [...] I am currently testing an Adyen integration with Sylius and need to verify Apple Pay with Cartes Bancaires in the sandbox environment. Could you please advise how Cartes Bancaires can be tested in Apple Pay Sandbox (e.g. cards details)? [...] Testing Carte Bancaires (CB) with Apple Pay is more complex than testing Visa, or Mastercard alone because: CB cards in France are almost always co-badged (CB + Visa or CB + Mastercard) Apple Pay requires explicit CB network declaration in your payment request The Apple Pay sandbox and Adyen sandbox are two separate systems that must be aligned Raw card numbers are never used directly in Apple Pay — everything goes through tokenization Please contact Carte Bancaires or Adyen directly for use test cards from Adyen's sandbox, as the test cards are updated periodically. However, with Apple Pay those raw numbers are not entered directly. Apple Pay generates an encrypted payment token (DPAN + cryptogram

Hi @Razee, You wrote: [...] When I go to Wallet → Add, I only see options for Credit or Debit Card or Travel Card. The option to add an Apple Pay Sandbox Card is missing, and when I try entering the test card numbers from Apple’s documentation [...] This is a very common misunderstanding about how Apple Pay Sandbox Testing is set up. The root cause of your issue is that signing in under Settings > App Store > Sandbox Account is for In-App Purchase testing only — it has absolutely no effect on Wallet or Apple Pay. Apple Pay Sandbox requires the Sandbox Apple Account to be signed in as the primary iCloud account on the device — not as the App Store Sandbox Account. These are two completely separate things: Settings > App Store > Sandbox Account: In-App Purchase (StoreKit) testing only Settings > [Your Name] (primary iCloud): Full device identity including Wallet As @TapThatApplePay also mentioned, don't do this on your primary persona

Hi @tkardile, You wrote: One of the payment methods is Apple Pay. The payment method is rendered, but the Apple Pay button is not clickable. We tried debugging it but could not identify the root cause. Could you advise how this issue can be fixed? Renders but not clickable is a very specific symptom. It means: The ApplePaySession availability check passed (device/browser is eligible) Adyen successfully initialized the Apple Pay component Something is blocking the click event or preventing ApplePaySession.begin() from being called This could be due to Content Security Policy (CSP) blocking from Salesforce B2B Commerce, as they are known for enforcing strict CSP headers. If so, that means Adyen's Apple Pay Drop-in makes calls to Apple's servers during the merchant validation step, and Saleforce's CSP may silently block these requests. To resolve this, review the support channels for Salesforce to learn how to add CSP trusted sites. I'd recommend adding the domains mentioned below (in addition to any Adyen Check

Thanks for the post with all the details and descriptions of what you are trying to accomplish. I’m more interested in the final goal for the app instead of being a replacement for the existing functionality instead of using it to be compliant with the location and local laws? What is the exact boundaries of privacy model for the Screen Time API that you are trying to get to? The designed the FamilyControls and DeviceActivity frameworks with strict data boundaries. Detailed usage data is legally and technically treated as highly sensitive, and the framework intentionally forces that data to remain on the device where it was generated. The DeviceActivityReport extension runs in a highly restricted sandbox explicitly designed this sandbox to be age and location based. Any attempt to exfiltrate the raw data you iterate over in makeConfiguration(representing:) will be blocked by the sandbox, as you saw with the CFPrefsPlistSource denial? For DeviceActivityReport(users: .children) to del

Hi @yoyoismycat, You wrote: We're working on in-app provisioning for wallet access passes. When testing the in-app provisioning on a sandbox account, I get an error saying software update required. [...] The most common cause for this error is due to the devices OS version being below the minimum requirements. To use PKAddSecureElementPassViewController, you need iOS 13.4 or later. For Wallet Access passes, you need iOS 15 or later. For PKAddShareablePassConfiguration or must-pass provisioning in a single sheet, you need iOS 16 or later. For Access passes with PKSecureElementPassActiviationState, you need iOS 16.4. Confirm the exact iOS version of your test device. If you are testing on Simulator, note tat the Secure Element provisioning is not supported and will always fail. You must test on a physical device. Since you only receive this error in the sandbox, this may likely be related to a Pass Type ID or certificate mismatch. In the sandbox environment, Apple users a separate cer

Hi @MrDanSB, You wrote: Given that the math seems correct and the public key hashes match, could there be an environment mismatch (Sandbox vs. Production) or a domain validation issue causing Apple to encrypt the payload with a dummy PartyV or scramble the data altogether? The Tag mismatch in AES-GCM almost always means the derived key is wrong, not the decryption step itself. Given what you've descried, there are several high-probability culprits beyond what you've already investigated: ECHD Shared Secret The KDF The exact value of PartyV ECHD Shared Secret Even when Bouncy Castle computes the correct EC point, the shared secrete Z must be exactly 32-byte big-endian X-coordinate of that point. Two common silent corruptions: BigInteger byte length stripping / sign inflation. Some libraries may return 33 signed bytes, or fewer than 32—the value needs to be exactly 32 bytes. Using Bouncy Castles' BasicAgreement vs ECDHBasicAgreement. All signing algorithms should use ECDH. The KDF Apple Pay Web uses AN

Hi @Jalley316, You wrote: [...] What is the best way to approach this from a lower environment perspective? [...] The Apple Pay sandbox environment allows you to test your implementation of Apple Pay, including merchant token notifications, using test credit and debit cards. To begin testing, you will need to: Create a sandbox tester account. Sign in to App Store Connect, navigate to Users and Access, then Sandbox, and click Testers to set up your accounts. Ensure the email address used for a sandbox account is not already registered as an Apple Account. Sign in with your sandbox account. On your test device, sign out of your personal Apple Account and sign in with your new sandbox tester account as the device's Apple ID. Add a test card. Go to Wallet on your test device and add a new card using manual entry with the provided test card numbers. Ensure your device's region is set to a country that supports Apple Pay. Initiate a payment request with tokenNot