Are there plans to support Storekit 2 receipt verification?

Michael Costa

That's correct, you get the TransactionID from deserializing PendingOrder.Info.Receipt (at least that is the method I'm using ). The reason why you want the TransactionID and NOT the OriginalTransactionID is because renewed subscription purchases will have two different values for this.

Just a couple questions so we have more context:

Do you have the Bundle Id field filled on the Apple Platforms page on brainCloud? This is still a requirement for validating purchases. You'll need to make sure to have one set up for your app on Certificates, Identifiers & Profiles and that it matches the Bundle Identifier in your Unity Player Settings.
Are you running CachePurchasePayloadContext() (docs) before VerifyPurchase()? This is also a requirement for purchases of itunes type.

Please let me know so we can look deeper into this! Thanks

peter

Yes, we still have the Bundle Id configured in the Application ID > Apple page on brainCloud.
Yes, we are still calling CachePurchasePayloadContext() with itunes and the payload. This code path hasn't changed as we've upgraded from 5.8 to 5.9

LEE JONG GUN

This post is deleted!

LEE JONG GUN

@Michael-Costa

"packetId": 13,
"responses": [
{
"data": {
"resultCode": 101,
"errorMessage": "Transaction id not found.",
"store": "itunes"
},
"status": 200
}
]
}

After configuring the App Store Server API, enabling “Use App Store Server API for legacy receipts (optional)” appears to cause legacy receipt validation to stop working. Instead, the system starts requiring a transaction ID.

In other words, checking it has the opposite effect.

We are currently running a live service using the existing receipt-based flow, so we have this option turned off—meaning we are effectively using it in practice (because enabling it breaks legacy). We are very concerned that if this behavior gets “fixed” later, it could cause issues in our live service. Please take this into account and ensure any patch/change does not introduce regressions for live operations.

Paul Winterhalder

HI Lee,

Can you message into our support system with the appId involved - and the profileId of a user who had the issue?

Thanks,

Paul.

LEE JONG GUN

@Paul-Winterhalder

Hello

Project 14594
Tester ID 1b5c9fce-a890-4d86-86aa-dd71263d0fc1

App Store \Server API has been fully configured in the current BrainCloud settings, and “Use App Store Server API for legacy receipts (optional)” is turned OFF.
This option must be disabled for the legacy receipt flow to function, so it is intentionally kept turned off in order to use the current setup.

When checking Verify Purchase in the user ID logs, the client has not yet been updated, so it is not sending a transactionId and is instead sending the receipt, following the legacy receipt-based flow.

Paul Winterhalder

Hi @LEE-JONG-GUN ,

Is that a sandbox receipt for that user? We seem to have found a second flow for sandbox purchases - not sure why there are two - maybe for older vs. newer receipts?

Anyway - we've created a patch and will be deploying it soon.

Paul.

LEE JONG GUN

@Paul-Winterhalder Yes, that’s correct. It is a sandbox account.

After the patch, it would be good if existing receipts continue to work by default.

Paul Winterhalder

Hi @LEE-JONG-GUN - the patch has been deployed. Let us know if it works better for you.

LEE JONG GUN

@Paul-Winterhalder Now, purchase validation proceeds normally regardless of the “Use App Store Server API for legacy receipts (optional)” option setting.