Postback url confirmation

[John Quigley]

Hi,

I have a question about post back url confirmation.  If a url is specified, then that server is supposed to confirm the transaction within 10 seconds or it will be canceled, according to the docs.  But what happens if my server records it as successful, but the response doesn't get back to google in time (or at all), so google cancels it?  In this case, I've credited the user for something he purchased but didn't get paid for it.  Is there some way for a server to query google to determine if a particular orderId has truly been completed?

Thanks,

John

[Nadim Ratani]

Hi John,

Thank you for your question.

At this time, there's no API to confirm order status, but you can see order status in the Merchant Center.

Nadim Ratani | Developer Programs Engineer | Google Commerce

[John Quigley]

Hi Nadim, thanks for replying.

Are they any plans to implement an API for confirmation?  Even if we can see the order status in a report, it seems pretty important to be able to fully confirm the purchase before crediting the user.

John

[Nadim Ratani]

Hi John,

I encourage you to keep an eye on this group for future announcements. I understand where you are coming from and please be assured that we are taking your feedback into account.

Regards,

Nadim Ratani | Developer Programs Engineer | Google Commerce

[Ed Chavez]

Piggyback on this thread....

It seems that what is actually occurring is that the order is processed and the user is notified of a good transaction - even if the postback url doesn't confirm....

On that note, are postbacks actually being sent (right now)? I was testing a few minutes ago, and it doesn't seem that my listener isn't even getting requests...I was testing the failed postback confirm/error flow and was surprised that I didn't have to induce it...am getting:

Uh oh. There was a problem.
We couldn't start your purchase because of a technical issue. 

 

[John Quigley]

Ed, I was actually having the same problem.  In the UI I received that message, yet I received notification on the client JS callbacks and via email that it completed successfully.  And I also have a postback url that is not being called.  I figured it was some misconfiguration issue with my setup that I need to debug, but maybe not.

In javascript console I see errors like this:

Invalid auth token. 620342327 vs undefined   default,sandbox_config.I.js:6

[Ed Chavez]

Sorry, misery loves company I guess :)

Yup:

• can see the similar in js console (no idea what it means though)...
  
• postback url isn't hit (no incoming request)
• buyer receives order email
• seller sees "good order" in order inbox....

Seems like a hiccup in Google sandbox.....

Ed

[Ed Chavez]

BTW, on  your question above, assuming things will work per documentation, if Google doesn't receive a "handshake" (your server didn't respond in time), your "failure callback" will be called....so you could still catch it....

It's just tough to test it now because of aforementioned current behavior.....still yes, your request for a "query api" is excellent.

Ed

[ad...@amuratech.com]

Exactly, now I can see the weird behavior that postback is coming to
'/' when page for buyItem loads. I don't understand the flow now.

[John Quigley]

I'm still getting the behavior Ed describes below as of today.  Does anyone else have their postback urls get pinged successfully?  Just trying to figure out if this is a configuration problem on my end or something wrong with the sandbox.  The only thing in my configuration that I haven't done is set up a bank account for my test seller.  The docs didn't mention that is needed, but is it?

[Ed Chavez]

Can confirm that since we've had the discussion, my handler isn't being hit at all - and things are pretty much what I describe above (still).

There's a pinned post in regarding downtime/upgrades to sandbox for tomorrow 6/1/11...so maybe its related.....

[Nadim Ratani]

Ed, John, and anyone else running into this issue:

I can confirm that this is a bug in the current sandbox environment and that our engineers are aware of this and an update should be rolling out soon. We will postback here when it is resolved :)

Thank you for your patience and for providing feedback, it is really nice to see active participation like this.

Regards,

Nadim Ratani | Developer Programs Engineer | Google Commerce

[Ed Chavez]

Seems we're back in bidness! :) Data is being sent to listener! 

Will just wait on Nadim's post on the other stuff  - re: failed postback handshake:

• results in "good" order 
• but buyer is presented with 'failed' message
• and success callback is called..

[Oliver Siegel]

1.5 year later, I'm going to check in: Is there a feature in place by now?

I just tried in the sandbox to just delay my script by 15 seconds. And obviously Google has cancelled the transaction and posted an error, but my script still kept running and followed through on all actions as if money had been received. 

I am considering this scenario because I don't know if my servers might have a delay. Successful transactions should trigger db queries, and if it takes a while to write in the db, then I'm out of luck...

Or does someone have a suggestion on how to implement a script that is delay free and does the db entry after sending the 200 OK response with the order ID in it. But then I guess the customer could be out of luck, if there is a problem with the db. But that's something I could fix later..

Well I just wanted to konw if there's a feature in place yet, which lets you double check both ends...

[Mihai Ionescu]

Hi Oliver,

You get notifications of a successful transaction on both server and client.

On the server side you get the postback which requires a reply within 10 seconds.

After that you get a client notification through the successHandler.

You should check both server and client notifications before you update the database and deliver the digital item to the customer.

Thanks,

Mihai

[Oliver Siegel]

Thanks for the quick response, Mihai! This sounds great, but I have one question:

Here it says "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."

Do you have a suggestion for me how I could make sure they play well together?

I don't want to credit my users until I am sure the transaction went through and I have the money, and I want to be sure that there were no errors due to a slow server response. But I also don't want users mocking the success of a transaction and triggering any scripts on client side...

Do I have to come up with some kind of a verification system for the client side response? Making sure it was a genuine response and not one mocked by the user?

If that is the case, do you know of any proven verification systems which I can adopt?

Hope my question makes sense

Thanks

Oliver

[Mihai Ionescu]

Hi Oliver,

If you get a successHandler notification and there is no transaction record on your server, then it is a fake.

If you get a successHandler notification and there is a corresponding transaction record on your server, then it is a valid transaction and you can deliver the digital item.

Your server being slow, thus causing a cancellation, will not help a fraudster. He will need to guess the order ID to fake a successHandler notification that will match the order ID from the server.

Also please note that if the transaction fails you will get a notification through the failureHandler and you can update your server records accordingly.

Thanks,

Mihai