Promo codes breaks remote server verification

[henrik-lindqvist]

Releasing promo codes for in-app purchases will (forever) prevent an app from using remote server purchase verification!

When a promo code is used for an in-app purchase (the PURCHASES_UPDATED intent) it will completely bypass the purchase flow so the app can't supply an "developerPayload", used for remote verification:
http://developer.android.com/google/play/billing/billing_best_practices.html#payload

Later when the app call getPurchases() to get owner products, the purchase data for promo purchases won't contain a "developerPayload" of course, but neither an "orderId", also used for remote verification using the Google Play Developer API:
https://developers.google.com/android-publisher/api-ref/purchases/products

How is an app supposed to verify in-app purchases made with promo codes?

Allowing users to redeem promo codes through the Google Play Store app, thus bypassing the purchase flow, seems like an major oversight which shouldn't be possible.

[kanetik]

@PaulRashidi I know this isn't going to be a quick fix, but this is a problem I'd like to know the solution for as well. Promo Codes are going to (soon) play a huge role in a couple projects I'm working on, and I'd love to be able to verify purchasers who use them.

[henrik-lindqvist]

The issue was posted to Stackoverflow on February 13th:
http://stackoverflow.com/questions/35381104/promo-codes-breaks-remote-server-verification

Google Play developer support was contacted on March 10th, given ticket [6-6452000010628], still no answer.

[PaulRashidi]

Thanks, give us a few days then feel free to ping again if we haven't responded yet.

[canxerian]

Hi @PaulRashidi, we are also facing this issue. I acknowledge that a promo code can be redeemed in the GP store and that there is no way to attach a developerPayload - would it be possible to receive the promo code in the receipt? This information can then be used to cross-check against a finite list of codes we have our end. At present there doesn't seem to be any way to differentiate between a cash purchase and a promo code redemption, other than the missing dev payload and orderId.

Thanks!

[henrik-lindqvist]

@PaulRashidi yet another month has passed without any response to neither ticket, stackoverflow or here. Any progress, or is the issue buried?

[PaulRashidi]

Hello, I'm not purposefully ignoring this, but there's an event in a few days that has been consuming all of my time lately. Please ping your ticket and I'll get back to this shortly after I/O.

[kenglou]

we are having this issue too. Hope to get the fix ASAP.

[PaulRashidi]

Is it possible to propose a test in a PR that simulates the issue?

[JeremyR34]

For information another StackOverflow post has been created in January: http://stackoverflow.com/questions/34979420/in-app-purchases-made-via-promo-codes-return-empty-developer-payload-string

[kenglou]

In my case, I just wish that when I redeem the promocode in the game purchases, it will just return success as normal items with the developer payload string that i passed in, so that I won't be needed to ask the player to restart the game and load the in app purchases from GetPurchases function, this seems more seamless and flawless as a player.

[edrianolima]

I managed to make sales in a test application, but I can not add a product in my main application, I always get a message saying "The requested item is not available for sale." Has anyone ever experienced this?

[jacobras]

Any update on this, @PaulRashidi?

[4ybaka]

@PaulRashidi probably you are really not purposefully ignoring this issue but it seems like that. Meanwhile half year passed and we still have no any workaround or information about regular fix.

[Vahhab]

I also provided some details here: http://stackoverflow.com/questions/39112132/android-google-play-promotion-code-for-inapp-billing. As you can see developer payload and order id are both empty so everyone can fake this responses somehow and it may incur some security risks.

[rpattabi]

Developer payload is the main defence against fake purchases. (As suggested by Google guy @netomarin here https://www.youtube.com/watch?v=tRpGcA4IM5Q)

Now that purchases using promo code do not return developer payload even if the purchase is initiated within app, there is no defence against fake purchases.

Developer payload should be returned irrespective of payment method (credit card or promo code). If the redeeming of promo code happens through play store, we could be asked to provide static developer payload through developer console. So it is easy for google play to provide developer payload in any scenario.

Google, Are you working on this critical issue?

[thiagolr]

Any update on this?

[aaru]

@google any update on this? We are in Oct 2016 end and still no update...

[aaru]

Finally had a live chat with Google team, shared this link and here is what they said..
Xictoria 11:27 PM (Oct 31st 2016)
Thanks for waiting. I've confirmed that this is a known issue that our tech team is working on, but unfortunately I don't have any kind of ETA or any updates about where they are in terms of progress.
Xictoria 11:28 PM (Oct 31st 2016)
I'd be happy to go ahead and escalate this ticket to them to let them know there are further complaints, but I'm afraid that's all I can really do.

[ekstro]

While we all are waiting for fix - do you have any temporary solution for this problem? I don't see any possibility to check if payment was done with credit card or promo code... Do you bypass payload check for this moment?

[henrik-lindqvist]

@ekstro There's no workaround. Just don't release promo codes. If you do, the app will be much easier for pirates to bypass, since you will never be able to verify (promo) licenses, ever again.

[joelfernandes19]

Any updates on this?

[markushi]

@PaulRashidi any updates on this? This bug makes the IAP developer payload useless at the moment.

[netomarin]

Hi

First, thanks for all that commented this issue.
We reviewed our guidelines and internal APIs, and since the developerPayload is not supported across all features on In-App Billing API (including promocodes), we are removing the recommendation to use it as a security check.

As you can see in our documentation, on the page Implementing In-app Billing (https://developer.android.com/google/play/billing/billing_integrate.html) we've added a recommendation:

Caution: Don't use the developerPayload field for security validation purposes. This field isn't always available when completing tasks related to In-app Billing. For more information about security best practices, see the In-app Billing Security and Design guide.

Our recommendation is to validate on your own backend, using the Play Developer API.

Thanks
Neto

[henrik-lindqvist]

@netomarin You've seem to have missed a paragraph in the billing documentation:
https://developer.android.com/google/play/billing/billing_best_practices.html#payload

[netomarin]

@henrik-lindqvist the paragraph just explain that is a good practice to check if the developerPayload received, "matches the token that you sent previously with the purchase request".
But you can notice that the section's title is: "Verify the user's purchases on a server"
As I mentioned earlier, developerPayload is not supported across all features on In-App Billing API, but is on some cases.

[henrik-lindqvist]

@netomarin I'm confused. If developerPayload isn't supported across all features, how can it be good practice checking it? Either we can rely on and enforce a matching developerPayload, or we can not. Only checking responses which has a developerPayload seems useless since pirates will just mock a response without it.

[netomarin]

@henrik-lindqvist it's no recommended to use as security feature, but you can use it for any other reason you want, so, if you use, it's a good practice to check if it matches.
And, again, don't rely on developerPayload to do your security validations, as I've mentioned and pointed on our docs.
Our security recommendation is to check on your own backend.

[loki666]

Security rule number 1.
Client side can be compromised. Don't trust it.