Are there plans to support Storekit 2 receipt verification?

LEE JONG GUN

This post is deleted!

LEE JONG GUN

"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!