[MNA-3651] [iOS] Storekit 2 - Add additional transactions and renewal info to v1/receipts API

[eduard-stern]

…ipts API

Checklist

• If applicable, unit tests
• If applicable, create follow-up issues for purchases-android and hybrids

Motivation

Storekit 2 - Add additional transactions and renewal info to v1/receipts API

MNA-3651

Description

Extends our purchases-ios-spm fork to augment the existing /v1/receipts proxy call with two additional fields:

transactions — JWS tokens for all verified transactions from StoreKit.Transaction.all
renewal_info — JWS renewal info tokens fetched via Product.SubscriptionInfo.Status for all subscription groups

Unit tests added in the fork:

TransactionPosterTests — stubs the fetcher with known JWS arrays and asserts they reach MockBackend

BackendPostReceiptDataTests — verifies the values pass through the Backend → CustomerAPI layer, that they serialize correctly as transactions/renewal_info in the JSON body, and that both keys are omitted entirely when nil

[Seitk]

Hi @eduard-stern is it possible to have a feature toggle wrapping the logic?

postParamsHeader is part of the signature calculation in RC SDK and our backend. So adding new data might break the signature and failing all the entitlement verification if we didn't handle it well.

[eduard-stern]

Hi @eduard-stern is it possible to have a feature toggle wrapping the logic?

postParamsHeader is part of the signature calculation in RC SDK and our backend. So adding new data might break the signature and failing all the entitlement verification if we didn't handle it well.

I can add a feature toggle as a safety net.
On the signature concern: transactions and renewal_info are only added to the JSON body, not to contentForSignature in PostData. So the X-Post-Params-Hash header is computed over the same three fields as before (appUserID, fetchToken, appTransaction) and won't change.
The new fields are invisible to the signature calculation.
For the toggle itself, I can add a flag to InternalDangerousSettingsType (following the existing pattern in the fork), or have it gated on the main app side before the fork is wired in?

[Seitk]

Hi @eduard-stern is it possible to have a feature toggle wrapping the logic?
postParamsHeader is part of the signature calculation in RC SDK and our backend. So adding new data might break the signature and failing all the entitlement verification if we didn't handle it well.

I can add a feature toggle as a safety net. On the signature concern: transactions and renewal_info are only added to the JSON body, not to contentForSignature in PostData. So the X-Post-Params-Hash header is computed over the same three fields as before (appUserID, fetchToken, appTransaction) and won't change. The new fields are invisible to the signature calculation. For the toggle itself, I can add a flag to InternalDangerousSettingsType (following the existing pattern in the fork), or have it gated on the main app side before the fork is wired in?

That's nice Eduard, I think ultimately we should also add in the new fields into post params hash (maybe also toggled by the flag). It would be good to have more granular control on setting in case there are new changes we will make in the forked SDK

[eduard-stern]

add in the new fields into post params hash (maybe also toggled by the flag)

Thanks, Philip, added a sk2AdditionalTransactionDataEnabled flag to InternalDangerousSettingsType. When true both sends the fields in the body and includes them in the X-Post-Params-Hash via contentForSignature. I'll open a PR in Goodnotes to pass the feature flag to RC