Quick update - after more testing, this seems to be isolated to only when non-existent Transaction IDs are sent to the Production endpoint.
With a Production Transaction ID on Production endpoint, seeing ~200-300ms latency.
Sandbox Transaction ID = 3-4 second latency on Production, 200ms latency on Sandbox.
Using a nonexistent transaction ID = 3-4 second latency on Production, 300-500ms latency on sandbox.
ahogue9000
Users receive reputation points by contributing quality content to the forums.
Posts include post and replies published on the forums.
Post authors can mark replies as Accepted to indicate successful solutions.
Apple Developer Forums admins can mark replies as Apple Recommended to indicate an approved solution
Last seen
User for
Post
Replies
Boosts
Views
Activity
Thank you for the quick response here! I've been experiencing this consistently for last 24 hours - I just filed a Feedback Assistant ticket to escalate.
To clarify - we're migrating to a StoreKit 2 solution, so wanting to move away from verifyReceipt on our backend at the same time.
2 questions:
Does VerificationResult.jwsRepresentation on the client matches up with JWSTransaction in the App Store API?
If I sent the client jwsRepresentation to our server, is there a way to verify that the transaction's underlying subscription is also active without hitting the App Store API?
It does seem like we can get transaction-related info with jwsRepresentation, but the reason I was using Get All Subscription Status endpoint is because subscription status is also included in that response.