In App Billing orderIDs and safely validate order

I published few months ago a free Android app with In App Billing where you can buy a durable product. When coding billing part, I didn't pay attention to order validation in fact I used with code when purchase was finished:

IabHelper.OnIabPurchaseFinishedListener mPurchaseFinishedListener = new IabHelper.OnIabPurchaseFinishedListener() {
        public void onIabPurchaseFinished(IabResult result, Purchase purchase) {

            if (mHelper == null) return;

            if (result.isFailure() && result.getResponse() == 7) {
                // Already bought
            } else if (result.isFailure()) {
                return;
            }

            if(purchase != null)
            {
                // add premium features
            }
        }
    };

I know it's not a safe check.

First question. Now I'm able to see through Analytics that I get transaction with two orderID types:

GPA.XXXX-XXXX-XXXX-XXXXX
[19 digits].[16 digits]

As I could understand, the second one was deprecated about 2 years ago (link), so why I'm still receiving that orderID? Also all the orders of the first type are visible in Google Merchant Console, while the second one are not. Is it safe to add a check on app start that retrieves the purchase and deactivate premium features if the related orderID is the second one?

Second question. Assumed that it's probably an hack and also assumed I don't think it worth to perform server-side checks, would make it safer is I implement a verifyDeveloperPayload when purchasing? As far as I could understand, most of the hacks in circulation (like Freeedom) don't spoof the developerPayload, which is computed at runtime based on Google account ID, so it should be enough.

Solution

I'm answering my own question because no one else did and I had gathered more information about this.

To the first question: If you receive orderIDs with the old format, just discard them because they are likely to come from Lucky Patcher and other similar tools trying to spoof orders.

To the second question: Most of the above quoted tools, also spoof developer payload and replay it in the response JSON, so don't trust it.

In the end, implementing a server side verification will definitely secure your application from IAB hacks. Of course, they can still decompile it and remove server checks, but you all already know this story.