You either reply to the objection (if you think you're right) or submit a new build (if they're right).

Submitted an app update on the 24th and it was live within 24h.

This will most likely be rejected.

Check the logs when testing with public link.

The url for your app is based on AppID and should never change, assuming it's the same app. Make sure you're not including the app name (which is editable) in the URL.

Apple Review Team doe indeed usually use iPads. If you're unable to recreate, I'd add logging to know where/when the issue happens.

I'll set aside if it will be approved for the public but you could use script injection. function injectScript() { const script = document.createElement('script'); script.textContent = ` // Store the original fetch const originalFetch = window.fetch; // Decorate fetch with your custom logic window.fetch = function(...args) { // Your custom logic here console.log('Fetch intercepted:', args[0]); // Example: Add custom headers if (args[1] && args[1].headers) { args[1].headers = { ...args[1].headers, 'X-Custom-Header': 'MyValue' }; } // Call original fetch with modified arguments return originalFetch.apply(this, args); }; `; // Inject script into webpage (document.head || document.documentElement).appendChild(script); // Clean up - remove the script tag after injection script.remove(); } // Execute the injection when content script loads injectScript();

The notificationType from Apple you are looking for is "REFUND". Expired will only be true after the time frame of theninapp/subscription. In your example REFUND is notified immediately (after the 3 months), EXPIRED occurs after the full term (1y).

that's what ETag is used for. Might be a bit fragile depending on how requests and responses are structured but no reason why ETag shouldn't work. Obviously implementing your own solution provides more flexibility.

Some of the information was previously available but then got stripped out a couple years back by new iOS versions.

You will need a Developer account. Then, you can do: Ad Hoc Distribution (provide you iPhone UDIDs, Distribute via AirDrop, email) TestFlight both will last for 1year.

This smells like a Safari-side change/regression in the capability probe, not in the payment sheet itself. Treat applePayCapabilities() as advisory only for now. Implement a graceful fallback: always show the button when Apple Pay is supported, then try to launch a session. Use canMakePayments() (and optionally canMakePaymentsWithActiveCard) only to influence prominence, not eligibility. This is consistent with Apple’s guidance and long-standing WebKit advice. File a bug with reproducibles via Feedback Assistant. Assume this is a Safari capability-probe issue (and possibly anti-fingerprinting collateral) rather than your integration. Don’t block Apple Pay on the probe; keep the button visible and let the session tell you the truth. This both fixes your users today and aligns you with Apple/WebKit’s recommended UX.