Feature to fetch google voided transactions

[kelchy]

before i do a pull request, can you guys check if you think this can be added into this project?

https://github.com/kelchy/node-iap

it is not directly related to verifying payments so i am not sure. however, this is something important
to developers offering inapp purchases. recently we got a lot of cheaters who made a lot of refunds.
this would help everyone in the long run.

i am not sure how you guys want to format the readme for this so asking for help.

[ronkorving]

Hi @kelchy,

That's a very interesting thought, I wasn't familiar with this API. So I found this documentation on it. One thing that scared me is that you are using a payment object (but only really to pass the package name), which indicates to me that you would wanna use it for all your incoming payment receipts?

If that is the case, this (from the docs) really scares me:

The Voided Purchases API sets the following quotas on a per-package basis:

100 queries per day. (The day begins and ends at midnight Pacific Time.)
30 queries during any 30-second period.

So I think the API would probably need to look a bit different for this to be usable. What do you think?

[kelchy]

i'm definitely open to suggestions

the fork i created is a proof of concept. developer can define when to call the function.
it does not have to be before, during or after verification. the intention is to have it available
if developer needs it. for example, in my case, i call it every hour.

i used the payment object to conform to how we do it for verification, of course receipt and token will
not be required for this. only the productId and keyObject are needed.

[ronkorving]

Do you know if any other receipt verification systems have a similar concept to what Google is doing here? I think it would help to establish what would make for a stable API.

[kelchy]

so far, have not seen any other project which implemented this

[justinpage]

@kelchy @ronkorving I believe we ran into a problem, similar to this, while analyzing some of our failures:

{  
  "message":"  Receipt:  failed to validate google receipt Received 410 status code with body:{  
    \n \"error\":{  
      \n \"errors\":[  
        \n        {  
          \n \"domain\":\"androidpublisher\",
          \n \"reason\":\"purchaseTokenNoLongerValid\",
          \n \"message\":\"The purchase token is no longer valid.\"\n
        }
      }
    }
  }
}

We are still strategizing how to handle these. I do think they may apply to the following:

• The user has revoked access.
• The token has not been used for six months.
• The user changed passwords and the token contains Gmail scopes.
• The user account has exceeded a certain number of token requests.

At least this is what I was interpreting from this:

https://stackoverflow.com/questions/45688494/google-android-publisher-api-responds-with-410-purchasetokennolongervalid-erro

We've somewhat alleviated this issue by allowing our apps to send us a new receipt when entitlement does not match. That is, our API says the user has no active subscription but the apps do. We use this receipt to update our records with. Why? Because the obvious source-of-truth is the apps. They work directly with the external billing system --in this case, google.

Of course, there are other things you'll need to consider but I thought I share this tidbit with you. Maybe all of this is totally unrelated to this thread but its one thing we've encountered with some of our customers.

[justinpage]

@kelchy let me know if you have any thoughts on the above.

[kelchy]

Justin, unfortunately, we have not yet encountered this issue on our side. i think it should be a case to case basis, in our app ecosystem, this will be treated as an error and our users need to get in touch with customer service. Kelvin Chua

…

On Fri, Oct 13, 2017 at 5:23 AM, Justin Page ***@***.***> wrote: @kelchy <https://github.com/kelchy> let me know if you have any thoughts on the above. — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#26 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AGxwWIR4Iex8prEqivY-W5euZrX9C8yxks5sroNlgaJpZM4McMI5> .

[justinpage]

This is actually something we've been considering on our side too. We have bad actors who like to subscribe and then immediately cancel. All in all, I can see this as an option in fighting free-trial abuse.

@kelchy I like the direction your fork is going. I would love to see this in a PR. One suggestion would be the option to send back another token so we have the ability to paginate data. We probably need to expand this so it includes start_time and end_time as well --basically interfacing what the API offers.

Good idea!