I'm still facing the issue (despite earlier comment that it's fixed). macOS is up-to-date (macOS 13.1, 22C65) no system updates are available. I cannot refresh the receipt either. I'm always returned the old receipt from just before I upgraded to Ventura. <SKReceiptRefreshRequest: 0x600002928360>: Finished refreshing receipt with error: Error Domain=ASDErrorDomain Code=500 "Failed to write receipt to URL: file:///Users/jeko/Library/Containers/447F8668-DE02-4E43-8350-6AEED8A3408E/Data/StoreKit/sandboxReceipt" UserInfo={NSDebugDescription=Failed to write receipt to URL: file:///Users/jeko/Library/Containers/447F8668-DE02-4E43-8350-6AEED8A3408E/Data/StoreKit/sandboxReceipt, NSUnderlyingError=0x6000026f2490 {Error Domain=NSCocoaErrorDomain Code=513 "You don’t have permission to save the file “sandboxReceipt” in the folder “StoreKit”." UserInfo={NSFilePath=/Users/jeko/Library/Containers/447F8668-DE02-4E43-8350-6AEED8A3408E/Data/StoreKit/sandboxReceipt, NSUnderlyingError=0x6000026f3720 {Error Domain=NSPOSIXErrorDomain Code=1 "Operation not permitted"}}}, AMSServerErrorCode=0} After removing /.../Data/StoreKit/ as an attempt to fix this manually, the problem remains, no receipt are created, I get a similar error.

If the payment got declined, you shouldn't receive the approved event in your javascript application. An error event should be triggered.

It has happen more and more for us since May. Monitoring the running average request processing time and implementing your own timeout and retry based on that value gives good result (since retrying the request works in most cases). It's unfortunate that we have to put this in place. The Apple's API will have to get more reliable as this is quite a critical one, resulting in lost revenue.

Some info like the subscription expiration date can only be retrieved by validating the receipt with Apple. You can validate with Apple right from your app (which isn't recommended by Apple). You can also use a receipt validation service like Fovea.Billing which provides a REST API doing the receipt processing for you.

Since original_transaction_id is used as a primary key for Apple subscriptions, knowing if it is the same for all family member or not has major architectural consequences. For now, our implementation ensure only 1 user can use a given subscription. If original_transaction_id is different for all family members it'll still work fine. If not we have to re-architecture our solution. However, we also use the transactions to estimate revenues (MRR, ARPU, etc.) If transactions id are different but are not linked together in some way we will count revenues twice, which will mess up our stats. Thanks for your clarification.