Are there plans to support Storekit 2 receipt verification?

[Michael Costa]

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.

[peter]

Thank you for the advice, we have now managed update our Application IDs.

However:

• We always get a 101 Transaction id not found failure from Brain Cloud when attempting to verify an in-app purchase.
• When Use App Store Server API for legacy receipts is checked, we also get a 101 failure when testing with older builds that use Brain Cloud 5.8 client 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 the TransactionID, and not the OriginalTransactionID - 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.Receipt returns a json string which has TransactionID as one of it's fields.

The data we submit to VerifyPurchase() looks something like this:

{"excludeOldTransactions":false,"transactionId":"2000001103879447"}

[Michael Costa]

Hello @peter.

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:

1. 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.

2. 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]

1. Yes, we still have the Bundle Id configured in the Application ID > Apple page on brainCloud.
2. 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.

[Paul Winterhalder]

Cool - glad it works for you now!

[Ralph]

Hi, i'm also trying to get this working. Here's my current problem:

My request:

{
      "service": "appStore",
      "operation": "VERIFY_PURCHASE",
      "data": {
        "storeId": "itunes",
        "receiptData": {
          "transactionId": "2000001110852583",
          "excludeOldTransactions": true
        },
        "requestPacketId": 7
      },
      "requestPacketId": 7
    }

and the response:

{
      "status_message": "Internal server error (message): class java.lang.Long cannot be cast to class java.lang.String (java.lang.Long and java.lang.String are in module java.base of loader 'bootstrap')",
      "status": 500
    }

[Ralph]

when i purchase the item again, i get a 200 status response but with the error message "Item already processed".

[Paul Winterhalder]

Is the IAP product set as consumable? Is it a new receipt that you're passing in? Is there an appId that we can use to check your logs @Ralph ? (feel free to send the info in via the regular private support channel)

[Ralph]

ok, i sent the info via bot.

[Paul Winterhalder]

Hi @Ralph - we found the issue. It's a path that is unique to apps that are using the older purchase collection storage format (which changed in 3.9). A fix is on the way. Thanks so much for reporting this!

[Paul Winterhalder]

Hi @Ralph - the patch has been deployed. Hope it works better for you now!

[Ralph]

I can confirm it works now. Thanks!