I said - background script. In the manifest file of browsers extension (chrome, firefox, edge) you have the manifest.json in which you define what is the background script. After I converted the extension to a Safari extension, Any access from the background script to window.sessionStorage was denied, which is extremely weird. Should I configure anything in the Xcode project after the conversion to solve that problem? Is it a Safari converter bug? Anything else?

Anybody home?

Hi @bweinstein, for me accessing localStorage and sessionStorage in a background script of Safari extension doesn't work. I can't provide a sample extension now. @bweinstein, can you first confirm that accessing sessionStorage from a background script works for you without SecurityError?

I checked. It looks like Apple bug. Other people complained in Stackoverflow in the recent days. When you choose Automatic manage signing, it makes the Provisioning Profile become "None Required", but it looks like it is required...

It's very strage that Apple chose to make it so complicated. In other "normal" payment providers you simply have the option to pass a CUSTOM_FIELD when sending the user to the payment screen. Then, in the IPN (The server notification) they simply send you back this CUSTOM_FIELD. So you can for example simply pass the user_id in this field, and get it back from the server, to easily correlate the server notification to a user. That's it. If I understand correctly, this architecture that Apple chose, besides being complicated, is also not safe. When a user buys inside the app, you need to take the receipt from the App, send to your server (together with the customer id!), and then verifyReceipt with Apple, and then save in your DB. If, for any reason, after the customer finishes the buy, the app crashes OR the internet communcation fails, and you dont send the receipt to your server, it will never be correlated to the user id => serious bug.

Anybody home?

Same problem here. In addition, what happens if I delete the database and want to start fresh? How to "reset" everything?

But what to do if the sandbox email address is not a real email address?

@Apple - are you going to solve this nightmare?

This is the solution: Get the application via testflight, as a real tester account and install the app locally on the phone In iphone settings, log out from the real app store id, and log in with the sandbox account (not a tester account). Open the already-installed app, and pay. It will use the sandbox account.