Why confirm purchase using postback URL?

Question

Google Wallet docs (for digital goods) say:

Note: These callback handlers are not secure. Someone could use Firebug or the Chrome Developer Tools to call one of the functions, mocking a success or failure. You should confirm the purchase on the server.

_{The link in the quote being to specifying a postback URL.}

But since the jwt is signed by Google - why is that needed? We can simply check the signature of the success handler's jwt in the page's codebehind on the server.

_{(And if signing isn't enough - it shouldn't be enough at the postback url either, because if someone discovers the url - they might send a POST there and the problem returns.)}

Answer 1

1. The purpose of the callback url is to let you know that a purchase has been made
2. You verify the posted data before you actually "consume" the data, it shouldn't matter if your postback url is "discovered" in the wild.
3. You tell Google that you were able to successfully record said order in your systems and that you can "fulfill" said order. Otherwise, if for any reason your end wasn't able to record/process/etc the order, meaning you won't "fulfill it", then the user (buyer) has to know as well.

I haven't tested this (I use postback url)

The documentation states *IF* you specify a postback url . So you can try not providing one and process the way you describe above (which is still "server side").

Possible issue

Assuming your test works, the difference between the two:

• in the scenario with the postback url, all parties concerned, buyer, you and Google are "in sync" - if you can't fulfill for whatever reason, have some server issue on your end, etc., then the transaction fails (no order generated) for all.

• in the scenario without the postback url, assuming a success, the transaction may have different states:

  • Google : Good, recorded, in buyer's Wallet transactions list
  • Your systems : possibly good, or not, or not even recorded
    • based on however your page processes the data at that time
    • any script error on the client/browser, or any other reason coming from the client side that may prevent your page from processing
  • User/buyer - has order in his/her Wallet transactions - "success" as far as Google is concerned

Hope this helps...

Update:

There is another "benefit" (could be critical in some flows) where security is concerned. With a postback url, you obtain the order details for yet-another-verification step (e.g. based on order-id). You can verify whether an order sent by/from client is "valid" (whatever business rule - e.g. if order-id exists then.....) because the success callback happens after the postback.

e.g. mock by replaying the same (valid) JWT (within bounds of iat/any expiration)

There could be myriad flows that sellers/devs come up with in their app so using "postback url verification processes" mitigates possible issues.

Hth....