Are there plans to support Storekit 2 receipt verification?
-
@Paul-Winterhalder Hello, is there guide for this menu?

and what is "Use App Store Server API for legacy receipts (optional)"?
-
Hello @LEE-JONG-GUN!
In order to fill out these values, you will first need to go your app on App Store Connect, then go to App Information. Under General Information you will see the app's Apple ID (this number should also appear in the URL for your app, FYI).
Next you will need to go to the Users and Access > Integrations > In-App Purchases page in App Store Connect.
From there you can find the Issuer ID. Next you'll want to click on the + button to Generate In-App Purchase Key. Give it whatever name you think suitable and it should add it to the page. You will then need to download this IAP subscription key; this should reveal the Key ID for that subscription.
The downloaded IAP subscription key file should be in a .p8 file format. You can open it with a text editor in order to view the Encoded Key. Ctrl + A then Ctrl + C to copy the entire file to the Encoded Key field. Also keep this file somewhere safe, you can only download it once!
That should be all that's required in order to make use of brainCloud's StoreKit 2 integration
.Finally the option for Use App Store Server API for legacy receipts (optional) is there to have apps with older integrations of the brainCloud client to make use of the new implementation with the old StoreKit 1 receipt system.
-
I have tried following the instruction (triple checked I have found and copied the correct fields) but I keep getting a "Itunes Inapp Integration fields incomplete" error when I try to save the page.
I am supplying:
App id > id shown in general information
Issuer id > Copied from in-app purchasing integrations page
Key ID > Copied form in-app purchasing integrations page (for the specific key)
Encoded key: Contents of the p8 fileThe copied error message
---- CONTEXT ---- { "email": "redacted@redacted.com", "teamId": "redacted", "accountNumber": "redacted", "appId": "xxxx", "appName": "Redacted", "profileId": null, "page_path": "/", "page_search": "", "page_hash": "#/app/design/core-app-info/application-ids", "page_location": "https://portalx.braincloudservers.com/#/app/design/core-app-info/application-ids" } ---- DETAILS ---- { "errorCode": 2020000, "errorMessage": "Itunes Inapp Integration fields incomplete", "reasonCode": 40660 } -
Hello @peter. Thank you for letting us know, we are currently looking into it.
As a work around, if you ENABLE "Use App Store Server API for legacy receipts (optional)", and the other fields are filled, you should be able to save. Afterwards you can DISABLE the optional value and it will still be able to save.
-
Thank you for the advice, we have now managed update our Application IDs.
However:
- We always get a
101Transaction id not foundfailure from Brain Cloud when attempting to verify an in-app purchase. - When
Use App Store Server API for legacy receiptsis checked, we also get a101failure when testing with older builds that use Brain Cloud5.8client and StoreKit1.- However, if we uncheck this, older builds transactions succeed as expected.
Given the fact we see the same behaviour on legacy transactions, I suspect this may be a fault on your side? If not, is there anything further I can do to investigate?
Notes on retrieving a transaction id with Unity.
We are using Unity IAP
5.1.2, it can be a bit confusing to find out where to retrieve theTransactionID, and not theOriginalTransactionID- as requested by the BrainCloud docs. (Though in my initial testing shows these ids are often the the same).Initially I parsed transactionID from the jws returned from the app store (a convoluted process), I then realised
PendingOrder.Info.Receiptreturns a json string which hasTransactionIDas one of it's fields.The data we submit to
VerifyPurchase()looks something like this:{"excludeOldTransactions":false,"transactionId":"2000001103879447"} - We always get a
-
Hello @peter.
That's correct, you get the
TransactionIDfrom deserializingPendingOrder.Info.Receipt(at least that is the method I'm using
). The reason why you want the TransactionIDand NOT theOriginalTransactionIDis 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) beforeVerifyPurchase()? This is also a requirement for purchases ofitunestype.
Please let me know so we can look deeper into this! Thanks

-
-
This post is deleted!
-
"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.
-
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.
-
Hello
Project 14594
Tester ID 1b5c9fce-a890-4d86-86aa-dd71263d0fc1App 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.