I'm implementing Apple Pay in my Flutter web app and I'm following the guidelines for domain verification using the apple-developer-merchantid-domain-association file. When I access the file at https://mydomain.com/.well-known/apple-developer-merchantid-domain-association through my web app, the browser silently downloads the file instead of displaying its content on the webpage. My question is: Is this the expected behavior for the apple-developer-merchantid-domain-association file? Should the browser download the file silently, or is there another step required, such as displaying the content on the webpage for verification purposes? I've consulted some resources and they indicate that the file download is the correct behavior. However, I'd appreciate confirmation from the community to ensure I'm implementing the verification process correctly. Summary is how do we know if apple has verified it?

Hello, We are experiencing a consistent delay when initiating Apple Pay sessions using the https://apple-pay-gateway.apple.com/paymentservices/startSession endpoint. Below is a detailed overview of our setup and the issue. Setup Our web service is hosted in AWS and there is a proxy server between our web service and Apple servers. We are passing the correct domain in the initiativeContext field of the startSession request. The .well-known/apple-developer-merchantid-domain-association file is hosted on a different domain, which is also correctly configured and associated with our merchant ID in the Apple Developer portal. Observed Behavior When the same request is made from a local development environment, Apple responds immediately (under 1 second). When the request is made from our AWS-hosted service, Apple responds with a valid session, but only after a consistent ~15-second delay. The content and response are otherwise identical — only the timing differs. We would appreciate any insights or suggestions from others who have faced similar behavior or from the Apple Pay team. Thank you in advance!

Hi,
 We’re implementing Apple Pay on the Web for a multi-tenant platform via a PSP. The PSP operates multiple HSM/clusters and gave us multiple CSRs, asking us to register all.
Our understanding: a Merchant ID can hold several PPCs over time, but only one is active at once. Questions Is there any supported way to keep more than one PPC active simultaneously for the same Merchant ID? If not, what does Apple recommend for web-only, multi-tenant setups: a single MID with PSP-side decryption & sub-merchant separation, or separate MIDs per brand/region? Any official guidance on PPC rotation and handling many domains for Apple Pay on the Web? links to official docs or prior Apple responses would be appreciated.

We are experiencing intermittent 403 Forbidden errors during Apple Pay on web merchant validation in our production and sandbox environment. Has anyone else started seeing 403 Forbidden errors recently (since mid-2025)? Why would merchant validation be sometimes successful and sometimes fail with 403? Could this be related to new Apple Pay gateway changes or stricter validation rules? Any additional debug steps or permanent solutions we should try? 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

{ "epochTimestamp": 1755169981033, "expiresAt": 1755173581033, "merchantSessionIdentifier": "SSH4ADF1D97A60B47FC8537037BE9892237_FF777A9CB5E9EDAB38A01E4EDF71CB5572F19153853DAC70ADC5AA3E75877CB4", "nonce": "b6f1e016", "merchantIdentifier": "7C52E6BFA112124092008236BE1EE49791E4E82E9082AD9AC98D55B03A088120", "domainName": "1960-ikffk.checkout.trypeppr.com", "displayName": "peppr", "signature": "308006092a864886f70d010702a0803080020101310d300b0609608648016503040201308006092a864886f70d0107010000a080308203ee30820394a00302010202080e7210e510586e34300a06082a8648ce3d040302307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3231303131303032313632395a170d3236303130393032313632395a306b3131302f06035504030c286563632d736d702d62726f6b65722d7369676e5f5543342d50524f445f4b727970746f6e5f45434331143012060355040b0c0b694f532053797374656d7331133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d0301070342000466e0ea0e787dcb3f66bc533189da2bda08ed9574e421117aa1af2cc310f6a8b19ca3e77ed00fa84e8df2ac8688e529866e76ebad89eda5b7c336e0f0d8a7d05da38202113082020d300c0603551d130101ff04023000301f0603551d2304183016801423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b304506082b0601050507010104393037303506082b060105050730018629687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65616963613330323082011d0603551d2004820114308201103082010c06092a864886f7636405013081fe3081c306082b060105050702023081b60c81b352656c69616e6365206f6e207468697320636572746966696361746520627920616e7920706172747920617373756d657320616363657074616e6365206f6620746865207468656e206170706c696361626c65207374616e64617264207465726d7320616e6420636f6e646974696f6e73206f66207573652c20636572746966696361746520706f6c69637920616e642063657274696669636174696f6e2070726163746963652073746174656d656e74732e303606082b06010505070201162a687474703a2f2f7777772e6170706c652e636f6d2f6365727469666963617465617574686f726974792f30340603551d1f042d302b3029a027a0258623687474703a2f2f63726c2e6170706c652e636f6d2f6170706c6561696361332e63726c301d0603551d0e0416041457c735942abd9ea2feccd3cbe7ede0a37c8cc5fa300e0603551d0f0101ff040403020780300f06092a864886f76364061d04020500300a06082a8648ce3d0403020348003045022100f2fa622622128cd1e1642084bc4117ccdede7289690e864cfb88abb43e04338e022065f85a90b82711d1fd762e0b59c45496e9e683c265c8279998e37872feae46ec308202ee30820275a0030201020208496d2fbf3a98da97300a06082a8648ce3d0403023067311b301906035504030c124170706c6520526f6f74204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b3009060355040613025553301e170d3134303530363233343633305a170d3239303530363233343633305a307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b30090603550406130255533059301306072a8648ce3d020106082a8648ce3d03010703420004f017118419d76485d51a5e25810776e880a2efde7bae4de08dfc4b93e13356d5665b35ae22d097760d224e7bba08fd7617ce88cb76bb6670bec8e82984ff5445a381f73081f4304606082b06010505070101043a3038303606082b06010505073001862a687474703a2f2f6f6373702e6170706c652e636f6d2f6f63737030342d6170706c65726f6f7463616733301d0603551d0e0416041423f249c44f93e4ef27e6c4f6286c3fa2bbfd2e4b300f0603551d130101ff040530030101ff301f0603551d23041830168014bbb0dea15833889aa48a99debebdebafdacb24ab30370603551d1f0430302e302ca02aa0288626687474703a2f2f63726c2e6170706c652e636f6d2f6170706c65726f6f74636167332e63726c300e0603551d0f0101ff0404030201063010060a2a864886f7636406020e04020500300a06082a8648ce3d040302036700306402303acf7283511699b186fb35c356ca62bff417edd90f754da28ebef19c815e42b789f898f79b599f98d5410d8f9de9c2fe0230322dd54421b0a305776c5df3383b9067fd177c2c216d964fc6726982126f54f87a7d1b99cb9b0989216106990f09921d00003182018930820185020101308186307a312e302c06035504030c254170706c65204170706c69636174696f6e20496e746567726174696f6e204341202d20473331263024060355040b0c1d4170706c652043657274696669636174696f6e20417574686f7269747931133011060355040a0c0a4170706c6520496e632e310b300906035504061302555302080e7210e510586e34300b0609608648016503040201a08193301806092a864886f70d010903310b06092a864886f70d010701301c06092a864886f70d010905310f170d3235303831343131313330315a302806092a864886f70d010934311b3019300b0609608648016503040201a10a06082a8648ce3d040302302f06092a864886f70d010904312204209378ff57580c3205e9ea38d985a2e9ca2db7f06db29b7560f585561a23894402300a06082a8648ce3d04030204483046022100fad47e840779070d097ef91cd4bfa5381d77426071cb38c1cdc77ff9460ba1470221009215c246893bff0983052caaae610a16117237e73ab36d859008e7b234670eaa000000000000", "operationalAnalyticsIdentifier": "peppr:7C52E6BFA112124092008236BE1EE49791E4E82E9082AD9AC98D55B03A088120", "retries": 0, "pspId": "7C52E6BFA112124092008236BE1EE49791E4E82E9082AD9AC98D55B03A088120" } This is generated in the onvalidatemerchant event handler, and passed into session.completeMerchantValidation. Using a sandbox account with linked cards, the next thing that happens is a "payment not completed" message in the ApplePay popup on the page, and the oncancel event is hit Inspecting the event, I don't see anything that hints at the issue. There is a sessionError object, but its code is "unknown" and the info object is empty.

We have an Apple Pay account and have successfully created and verified the payment processing certificate in our Apple Developer account. When initiating an Apple Pay payment, the Apple session is created successfully with the correct data return from api , but it is not accepted with the error: “Payment not completed.” The issue occurs even though the merchant validation step works without errors. Our websites where this is happening are: https://magicdeliver.com/ https://www.pulsarmodular.com/ Could you please help us identify the cause of the issue and guide us on resolving it?

We have developed Apple Wallet Extension for our App. The in-app provisioning for the card is working. However when we try to add the card from Wallet extension it gives error saying "Your issuer does not yet offer support for this card". From the apple documentation we can see the issues is same as mentioned in Scenario 2 at following link https://applepaydemo.apple.com/in-app-provisioning#8.4 We are getting eligibilityStatus as 0 Below is the response from Wallet captured using SysDiagnosis https://crt-pod1-smp-device.apple.com:443/broker/v4/devices/0434320BCB1A90022306073796318273728D0A367FA927F4/cards 200 Time profile: 1.77856 seconds { x-conversation-id = ...... Content-Type = "application/json" x-pod = "crt-pod1" x-xss-protection = "1; mode=block" Server = "Apple" x-pod-region = "paymentpass.com.apple" regionbrokerurl = "https://crt-pod1-smp-device.apple.com:443/broker" Date = "Wed, 06 Aug 2025 11:39:30 GMT" Content-Length = "488" x-envoy-upstream-service-time = "1400" Strict-Transport-Security = "max-age=31536000; includeSubdomains" cross-origin-opener-policy = "same-origin" x-keystone-correlationid = ...... x-content-type-options = "nosniff" Vary = "accept-language" x-frame-options = "SAMEORIGIN" } { applicationIdentifier = ......; auxiliaryCapabilities = { }; cardType = 4; deviceProvisioningDataExpected = 1; eligibilityStatus = 0; identifier = ......; learnMoreURL = "https://www.apple.com/ae/apple-pay/banks/ae/en-ae.html"; nonce = ......; paymentApplications = ( { appletTypeIdentifier = Argon; paymentType = Credit; } ); region = "paymentpass.com.apple"; sanitizedPrimaryAccountNumber = 7008; sanitizedPrimaryAccountPrefix = ""; }

Hi, We’re a franchise business with over 100 franchisees, and each franchisee has their own unique Merchant ID. We're building a single app that allows customers to place orders, and based on the selected franchisee, the payment needs to be processed through that specific franchisee’s merchant account. However, when we integrate Apple Pay and publish the app, it asks us to provide a payment gateways' Merchant ID, but we don’t use just one – we have many. How can we handle this situation? Is there a way to dynamically use multiple Merchant IDs in one app, depending on which franchisee the customer is ordering from?

Hello, We are experiencing an issue with Apple Pay integration in our application. We are using WKWebView to handle various payment methods, but we are unable to complete payments via Apple Pay. Upon debugging the WKWebView, we received the following error message: "400 No required SSL certificate was sent" when attempting to process the payment. Currently, we are using a Let's Encrypt SSL certificate. Could you please confirm whether this certificate is suitable for Apple Pay, or if we should be using a different SSL certificate?

I'm successfully using Apple subscriptions in my app, but I'm encountering SKErrorCodeDomain error 18 when trying to apply a subscription offer. I want apply offer code first time only for subscription. Below are details of what i set in appstore and what i have tested. Subscription Offer Details Offer Type: For the first month Customer Eligibility: New, Existing, and Expired Subscribers Code Status: Active Offer Code Creation Steps: App Store Connect → App → Subscription → Select Subscription Product → Offer Codes → Add → Add Custom Codes Signature Generation for Promotional Offers I'm following Apple's documentation to generate a signature: https://developer.apple.com/documentation/storekit/generating-a-signature-for-promotional-offers I’ve constructed the payload as instructed: appBundleId + '\u2063' + keyIdentifier + '\u2063' + productIdentifier + '\u2063' + offerIdentifier + '\u2063' + appAccountToken + '\u2063' + nonce + '\u2063' + timestamp Keys and Identifiers keyIdentifier, issuerId, and .p8 file are obtained from: App Store Connect → Users and Access → Integrations → In-App Purchase Test user created under: App Store Connect → Users and Access → Sandbox → Test Accounts Logged in with this account on the iPhone What I’ve Tried Verified all values used in the payload are correct Tried both seconds and milliseconds for the timestamp (as per documentation, it should be in milliseconds) Tried setting appAccountToken to: a valid UUID an empty string not setting it at all Used Apple’s sample code to generate a signature: https://developer.apple.com/documentation/storekit/generating-a-promotional-offer-signature-on-the-server Verified the generated signature locally, and it validated successfully: https://developer.apple.com/documentation/storekit/generating-a-signature-for-promotional-offers#Validate-locally-and-encode-the-signature Apple’s sample code to generate a signature Downloaded from const express = require('express'); const router = express.Router(); const crypto = require('crypto'); const ECKey = require('ec-key'); const secp256k1 = require('secp256k1'); const uuidv4 = require('uuid/v4'); const KeyEncoder = require('key-encoder'); const keyEncoder = new KeyEncoder('secp256k1'); const fs = require('fs'); function getKeyID() { return "KEYIDXXXXX"; } router.post('/offer', function(req, res) { const appBundleID = req.body.appBundleID; const productIdentifier = req.body.productIdentifier; const subscriptionOfferID = req.body.offerID; const applicationUsername = req.body.applicationUsername; const nonce = uuidv4(); const currentDate = new Date(); const timestamp = currentDate.getTime(); const keyID = getKeyID(); const payload = appBundleID + '\u2063' + keyID + '\u2063' + productIdentifier + '\u2063' + subscriptionOfferID + '\u2063' + applicationUsername + '\u2063'+ nonce + '\u2063' + timestamp; // Get the PEM-formatted private key string associated with the Key ID. // const keyString = getKeyStringForID(keyID); // Read the .p8 file const keyString = fs.readFileSync('./SubscriptionKey_47J5826J8W.p8', 'utf8'); // Create an Elliptic Curve Digital Signature Algorithm (ECDSA) object using the private key. const key = new ECKey(keyString, 'pem'); // Set up the cryptographic format used to sign the key with the SHA-256 hashing algorithm. const cryptoSign = key.createSign('SHA256'); // Add the payload string to sign. cryptoSign.update(payload); /* The Node.js crypto library creates a DER-formatted binary value signature, and then base-64 encodes it to create the string that you will use in StoreKit. */ const signature = cryptoSign.sign('base64'); /* Check that the signature passes verification by using the ec-key library. The verification process is similar to creating the signature, except it uses 'createVerify' instead of 'createSign', and after updating it with the payload, it uses `verify` to pass in the signature and encoding, instead of `sign` to get the signature. This step is not required, but it's useful to check when implementing your signature code. This helps debug issues with signing before sending transactions to Apple. If verification succeeds, the next recommended testing step is attempting a purchase in the Sandbox environment. */ const verificationResult = key.createVerify('SHA256').update(payload).verify(signature, 'base64'); console.log("Verification result: " + verificationResult) // Send the response. res.setHeader('Content-Type', 'application/json'); res.json({ 'keyID': keyID, 'nonce': nonce, 'timestamp': timestamp, 'signature': signature }); }); module.exports = router; Postman request and response Request URL: http://192.168.1.141:3004/offer Request JSON: { "appBundleID":"com.app.bundleid", "productIdentifier":"subscription.product.id", "offerID":"OFFERCODE1", "applicationUsername":"01234b43791ea309a1c3003412bcdaaa09d39a615c379cc246f5f479760629a1" } Response JSON: { "keyID": "KEYIDXXXXX", "nonce": "f98f2cda-c7a6-492f-9f92-e24a6122c0c9", "timestamp": 1753510571664, "signature": "MEYCIQCnA8UGWhTiCF+F6S55Zl6hpjnm7SC3aAgvmTBmQDnsAgIhAP6xIeRuREyxxx69Ve/qjnONq7pF1cK8TDn82fyePcqz" } Xcode Code func buy(_ product: SKProduct) { let discountOffer = SKPaymentDiscount( identifier: "OFFERCODE1", keyIdentifier: "KEYIDXXXXX", nonce: UUID(uuidString: "f98f2cda-c7a6-492f-9f92-e24a6122c0c9")!, signature: "MEYCIQCnA8UGWhTiCF+F6S55Zl6hpjnm7SC3aAgvmTBmQDnsAgIhAP6xIeRuREyxxx69Ve/qjnONq7pF1cK8TDn82fyePcqz", timestamp: 1753510571664) let payment = SKMutablePayment(product: product) payment.applicationUsername = "01234b43791ea309a1c3003412bcdaaa09d39a615c379cc246f5f479760629a1" payment.paymentDiscount = discountOffer SKPaymentQueue.default().add(payment) } Issue Even following instructions to the documentation and attempting various combinations, the offer keeps failing with SKErrorCodeDomain error 18. Has anyone else experienced this? Any suggestions as to what may be amiss or how it can be corrected?

Hi, I’ve been trying to integrate Apple Pay, but for some reason, the payment button is not showing up. The project is built with Laravel 11 and Vue. I imported the script as follows: <script crossorigin crossorigin src="https://applepay.cdn-apple.com/jsapi/1.latest/apple-pay-sdk.js" ></script> Then I added the following the steps: <style> apple-pay-button {{ --apple-pay-button-width: --apple-pay-button-width: 150px;; --apple-pay-button-height: --apple-pay-button-height: 30px;; --apple-pay-button-border-radius: --apple-pay-button-border-radius: 3px;; --apple-pay-button-padding: --apple-pay-button-padding: 0px 0px;; --apple-pay-button-box-sizing: border-box; } </style> <apple-pay-button buttonstyle="black" type="plain" locale="en-US"></apple-pay-button> I followed all the steps from the official Apple Pay demo: https://applepaydemo.apple.com/ I also configured the Content Security Policy (CSP) to allow all necessary resources. However, when I test my integration, the button doesn’t appear. I’ve checked the console, but there are no errors. At the same time, I have my certificate imported into the Keychain, and I’ve completed the entire process of creating both the certificate and the private key. However, when I try to validate the session using the certificate and key with Apple’s API, I get an error: 400 The SSL certificate error https://apple-pay-gateway-cert.apple.com/paymentservices/

Hi! I am working on automating the Apple Pay integration process in our CI/CD pipeline and would like to confirm whether a fully automated setup is currently possible for our preproduction environment. Right now, our process is as follows: A certificate is generated for the root domain and for each individual merchant subdomain. Both certificates are manually uploaded to our preproduction servers to test and verified via HTTP. We’d like to automate this flow in GitLab CI, mainly the generation of the necessary certificates programmatically or via API. However, from my research, it seems that Apple does not currently provide an API or any support to automate this task, but I’d like to confirm this directly with you. Is there any official support or workaround for this kind of automation? If not, do you have any plans to provide it in the future? Thanks in advance for your help.

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

I am trying to launch a PWA as an application on App Store, and got rejected cause of In-App Purchases. Application is about content generation and selling subscriptions for premium content. So thats why needed to implement In-App Purchases. I have created wrapper via PWABuilder. And it is looking great so far, now my question is about How can I implement In-App Purchases in the bundle which is already created. Any suggestions will be appreciated. More clarification:- I have that product running on Web right now, we have integrated Stripe for payment handling for subscriptions. If there is nothing we can do for In-App Purchases then we have to make purchases on website and then user will be able to experience the changes. We tried that, but then we got rejected for showing locked premium content on user's feed. Also can't show any CTA or Subscribe text or button.

We are developing a native iOS financial application called Tradu: Stocks, Forex, and CFDs (Apple ID: 6473443264), which embeds a WKWebView to render all user-facing logic. All user interactions—including authentication with MFA—occur inside this WKWebView. To access native functionality, we use postMessage() to communicate between the web and native layers. This approach has worked successfully for biometric authentication, for example. We are currently integrating Apple Pay In-App Provisioning and have a few questions regarding compliance with the documentation provided by our Issuer Host (Modulr). In the document titled Getting Started with Apple Pay: In-App Provisioning, Verification, Security, and Wallet Extensions (Version 4.0, February 2023), all examples are based on a fully native application. We’ve managed to integrate most of the In-App Provisioning flow via postMessage() up to the point of passing encryptedData to the Payment View. Apple Pay button inside WKWebView In Section 7: Frontend Overview, the user initiates the provisioning by tapping a native PKPaymentButton (SwiftUI example). In our case, this button is rendered inside the WKWebView, styled according to the Apple Style Guide. While the document references this approach as a “raw mark text supplement,” is this method acceptable and compliant with Apple’s UX and technical guidelines? MFA requirement before provisioning In Section 4: Security Guidelines, it is stated that the user must have passed MFA at least once before starting the provisioning flow. In our implementation, users must complete MFA on every login (including on recognized devices) before the provisioning UI becomes available. Even though this is not tied specifically to “unrecognized devices,” is our MFA requirement sufficient to satisfy Section 4.2? Summary: Is using a web-rendered Apple Pay button inside WKWebView (instead of a native PKPaymentButton) considered compliant? Is our MFA enforcement model (required on every login) aligned with the security requirements outlined in Section 4.2 of the Apple Pay In-App Provisioning documentation?

Hello, I'm trying to test an app clip in TestFlight with a Local Experience. Is there any way to test app clips "end to end" from a local experence? The clip I'm developing uses Apple Pay, so we'd like to be able to test the full experience using sandbox accounts. The documentation indicates that this is possible: documentation link Testers can also configure a local experience to launch the App Clip you distribute with TestFlight. However, you must still associate your App Clip with your website so testers can launch it from the TestFlight app. In addition, testers must launch the App Clip from an App Clip experience you configure for testing in App Store Connect at least once to ensure that the App Clip is cached on the device. I've had some success with running the clip from a local Xcode build, then installing a TestFlight build "over top" of the Xcode build, e.g. I can scan a QR code with a URL configured for a local experience and the card will show and launch the clip, but that seems to "expire" after a period of time. More information: App (but not App Clip) is currently live in the app store. App Clip is in TestFlight and launches using TestFlight experiences App Clip and App are associated with our website Am able to launch the app via QR code with a full installation from TestFlight Am able to see Local Experiences when the clip has been built locally and run on my device using Xcode Local Experience does not show when using a fresh install from TestFlight even when configured with the same values Local Expereince does show and work when using a TestFlight build installed over top of an Xcode build

I'm facing problem with in-app-provisioning in production application. When we try to tokenize (before T&C step) we are getting error from topic. I've also posted this in Feedback Assistant: FB18403577. I'll be very happy if someone could help me to get what is wrong with data or configuration of application.

I am trying to play around on the Apple Pay demo page (https://applepaydemo.apple.com) and I am getting the following error response. PaymentRequest AbortError: The operation was aborted. I am using the Payment Request API

Dear Apple Developer Support team, I would like to request an official confirmation regarding the handling of transaction status in the App Store Server API, specifically for the GET /inApps/v1/transactions/{transactionId} endpoint. As per our current understanding from the official documentation (Get Transaction Info), the API’s behavior appears to be: If a transaction is finalized and successfully processed by App Store, querying this API will return HTTP 200 OK along with transaction details. If a transaction is still in a pending or deferred state (such as awaiting Ask to Buy approval or pending authorization), the API will not return a 200, and instead respond with HTTP 404 Not Found or an appropriate error. Could you please confirm if this behavior is accurate and officially supported? Specifically: Does a 200 OK response guarantee that a transaction is finalized and successfully recorded on App Store servers? In cases where a transaction is pending approval (e.g. Ask to Buy), is it correct that GET /transactions/{transactionId} would return 404 Not Found until the transaction is finalized? We would greatly appreciate your confirmation to align our server-side logic for transaction validation accordingly. Thank you very much for your support! Kind regards, cuongnx