Posts

Post not yet marked as solved
17 Replies
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.
Post not yet marked as solved
17 Replies
@Apple - are you going to solve this nightmare?
Post marked as solved
5 Replies
But what to do if the sandbox email address is not a real email address?
Post not yet marked as solved
1 Replies
Post not yet marked as solved
5 Replies
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.
Post not yet marked as solved
6 Replies
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...
Post not yet marked as solved
3 Replies
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?