Question about new IAP v1.23.4 about GooglePlay packageName

[James15478]

• Security - Supports receipts from GooglePlay which omit packageName. These as are seen from v1.23.2’s purchase-recovery features.
• The purchasing receipt’s packageName is omitted by a GooglePlay historical purchase query APIs used by v1.23.2. When the RSASSA-PKCS1-v1_5 signature is valid and the receipt’s packageName is not included, the appBundleId / googleBundleId input into UnityEngine.Purchasing.Security.CrossPlatformValidator is ignored.

Is this only for old receipts that the packageName is potentially missing? Or does Google still provide receipts with a missing packageName currently? Any further information about the description of this change would help, I apologize I didn’t quite understand it all.

Is there anything we need to do on our side if we upgrade? (Currently on 1.23.3)
Currently I check the package name from the decoded receipt (from the validator) vs my own package name to make sure they match (as one of a few small security steps), I guess I should stop doing this?

[nicholasr]

Thank you for the sharing this finding about the ambiguity in the release note, and for reaching out for clarification @James15478 .

We expect fully complete receipts will be seen by apps which trivially upgrade to 1.23.3+.

These abbreviated receipts may appear with 1.23.2 however as that release has this feature as “always-on”, and 1.23.3 changed this feature to be “opt-in”.

In more detail:

Generally nothing has changed with Google, and internally all receipts will contain packageName when purchase details are fetched via the “primary” Google purchase query API or are collected as a side-effect of the normal purchase flow. Unity IAP 1.23.3 uses these flows to collect receipts by default.

Recently (1.23.2+) Unity IAP added a feature to make heavier use a different Google API, which acts as more of a historical query, to recover from interrupted purchases.

Google Play 的帳單系統  |  Google Play's billing system  |  Android Developers On that web page Google documents the responses for that API with a set of documentation tables. (Aside, some references seem to me to be crossed - in one field a reference is made to “table 6” which does not appear to match the referenced contents.) Importantly, the “getPurchaseHistory” tables show no “packageName”. This corresponds to the INAPP_PURCHASE_DATA_LIST key. Scrolling up the table documenting the responses to the “getPurchases” API, this does have packageName in its INAPP_PURCHASE_DATA definition. These are for the historical and what I’m calling the “primary” APIs, respectively. Unity IAP uses the getPurchaseHistory for its 1.23.2+ feature.

I expect receipts WITHOUT packageName might appear when a) a developer opts-in to the 1.23.3 feature using the Unity IAP API: bool IGooglePlayConfiguration.aggressivelyRecoverLostPurchases = true, and b) a player triggers this recovery behavior by experiencing a purchase which is both interrupted and successful. Anecdotally I have heard this interrupt may occur for one tenth of a percentage of purchases though I don’t have statistics to prove that. I can provide a reproduction scenario if that would be of help, using two phones and some quick “on/off” of the wifi hotspot setting.

Getting back to your question, to reiterate, unless your app is following the opt-in usage with 1.23.3, or it is using 1.23.2, that app will see full receipts, with packageName. Does this overlook an aspect of your question, @James15478 ?

[bmorgan-ksg]

Just as a quick piece of feedback, I believe it would be helpful to modify the release notes for version 1.23.3+ to include how to set the aggressivelyRecoverLostPurchases flag in more practical terms. It took me a bit to figure out that access to IGooglePlayConfiguration was available through the ConfigurationBuilder.Configure API

ConfigurationBuilder builder = ConfigurationBuilder.Instance(StandardPurchasingModule.Instance());
builder.Configure<IGooglePlayConfiguration>().aggressivelyRecoverLostPurchases = true;```

We've never had a need to modify configurations made available in this way as up until now our usage of the ConfigurationBuilder class has been limited to adding our product list.

It also seems as though this flag will be set when the project is built with "AGGRESSIVE_INTERRUPT_RECOVERY_GOOGLEPLAY" added to the Scripting Define Symbols field in the IDE or to an mcs.rsp file.

[James15478]

@nicholasr

Thank you for the sharing this finding about the ambiguity in the release note, and for reaching out for clarification @James15478 .

We expect fully complete receipts will be seen by apps which trivially upgrade to 1.23.3+.

These abbreviated receipts may appear with 1.23.2 however as that release has this feature as “always-on”, and 1.23.3 changed this feature to be “opt-in”.

In more detail:

Generally nothing has changed with Google, and internally all receipts will contain packageName when purchase details are fetched via the “primary” Google purchase query API or are collected as a side-effect of the normal purchase flow. Unity IAP 1.23.3 uses these flows to collect receipts by default.

Recently (1.23.2+) Unity IAP added a feature to make heavier use a different Google API, which acts as more of a historical query, to recover from interrupted purchases.

https://developer.android.com/google/play/billing/billing_reference#getPurchaseHistory On that web page Google documents the responses for that API with a set of documentation tables. (Aside, some references seem to me to be crossed - in one field a reference is made to “table 6” which does not appear to match the referenced contents.) Importantly, the “getPurchaseHistory” tables show no “packageName”. This corresponds to the INAPP_PURCHASE_DATA_LIST key. Scrolling up the table documenting the responses to the “getPurchases” API, this does have packageName in its INAPP_PURCHASE_DATA definition. These are for the historical and what I’m calling the “primary” APIs, respectively. Unity IAP uses the getPurchaseHistory for its 1.23.2+ feature.

I expect receipts WITHOUT packageName might appear when a) a developer opts-in to the 1.23.3 feature using the Unity IAP API: bool IGooglePlayConfiguration.aggressivelyRecoverLostPurchases = true, and b) a player triggers this recovery behavior by experiencing a purchase which is both interrupted and successful. Anecdotally I have heard this interrupt may occur for one tenth of a percentage of purchases though I don’t have statistics to prove that. I can provide a reproduction scenario if that would be of help, using two phones and some quick “on/off” of the wifi hotspot setting.

Getting back to your question, to reiterate, unless your app is following the opt-in usage with 1.23.3, or it is using 1.23.2, that app will see full receipts, with packageName. Does this overlook an aspect of your question, @James15478 ?

Yes @nicholasr Thank you very much for such a detailed response, very apprecated.

[James15478]

btw @nicholasr I noticed that on iOS I can test purchases successfully, but I now noticed that the In-App Purchase capability is not present in my xCode project. Is it working because it’s I’m in Sandbox mode, and do I need to add the capability?

[JeffDUnity3D]

@James15478

btw @nicholasr I noticed that on iOS I can test purchases successfully, but I now noticed that the In-App Purchase capability is not present in my xCode project. Is it working because it’s I’m in Sandbox mode, and do I need to add the capability?

Please stick to one topic per thread please. Nothing should have changed in this area. If it’s working for you, then I would not necessarily recommend any changes.