Comment by MicahWedemeyer | Hacker News Reader

Comment by MicahWedemeyer | Hacker News Reader

Parent Full thread

Here's an email that I received from the AWS support staff regarding a recent failed transaction. In the payment panel, the status was "failed". When I clicked through for more detail, the additional detail was "failed". So, I found an email address for support and sent off a request for more info, including the transaction number.

"Greetings from Amazon Payments.

I am sorry for the concern you have about the failed transaction (#XXX).

We are not able to provide transaction partners any information about a failed transaction. If the other party needs confirmation of the charge failure, they can contact us directly. However, as stated in our last message, we don't have details on why a credit card charge fails.

Once a transaction fails, we are not able to retry the same transaction. I am sorry for any inconvenience.

Thank you for using Amazon Payments.

Please let us know if this e-mail resolved your question:"

Hmmm, no. That did not answer my question. So, I'm supposed to ask my customer why their transaction failed, have them contact Amazon, and oh, would they pretty-please try to check out again?

Amazon understands the power of 1-click ordering, but cannot seem to grasp the conversion loss rate you see when you have to beg someone to check out for a second time. Getting them to click "Buy" the first time is hard enough.

We're not even running that many transactions, maybe 5-10 a day. Still, even with that we see probably a 5-10% failure rate.

To be fair, it may be that Amazon knows as little as they claim. Still, it's frustrating as hell to be completely in the dark about why stuff isn't working.

Also, it's quite easy to get to the form shown in the picture. Just log in to your payment console, click on a transaction (like one of the ones with a "failed" status), and click the big huge button that says "Problem with this transaction?" Here's another screenshot: http://files.getdropbox.com/u/145070/amazon_error.png

Whoah wait a sec: you're not using FPS are you, you're using Simple Pay. So with Simple Pay you don't get the error granularity you get with FPS however you do still get a return value in the Return URL: http://docs.amazonwebservices.com/AmazonSimplePay/latest/ASP.... You're probably getting a return value of PF which is Simple Pay's way of saying "no payment received. we'll spare you the details. reroute your customer back so they can attempt the transaction again." Your app has to check that return value and if it hears PF you need to have it redirect the customer back to the payment authorization screen (after notifying them "the transaction timed out etc.")

I'll bet that group of 5-10% is upset. They probably visited a "success" URI and naturally thought they were charged. If you find them (via the buyerEmail return parameter) don't tell them the problem is with Amazon, the truth is you didn't follow the developer doc: error-checking is your responsibility.

If you were using FPS you would get a more descriptive error. Your transaction status would be something like 'initiated', 'reinitiated' or 'temporary_decline' and for those you don't announce the error to the customer you just let FPS keep trying until you get a success or a (descriptive) fail. Net, FPS lets you better manage edge cases e.g. when the pipes fail.

Keep in mind the payments dashboard is for anyone with an amazon.com account so it's like hacking with mittens. It's not meant to be a full interface to FPS or even Simple Pay. You should not be doing your transaction error checking there. The reason Amazon Payments is "not able to provide transaction partners any information about a failed transaction" is because the failure is occurring within the context of an API and that API already informs you how to interpret all possible errors.

I guess there is another way to reach that error form after all. Looks like a user experience bug. Good catch.

I'm 99% sure we're using FPS and not Simple Pay. We're using the Remit gem (tylerhunt-remit on github), and I helped write portions of it. This was a while back, before they even announced Simple Pay or broke the API doc up into N separate docs. Man, that's irritating.

It just irritates me that pretty much everything has to be done via the API. Like I said, 5-10% of our transactions fail, meaning like 1 or 2 a week. If I could inspect the error and handle it from the console it would be much simpler than writing a ton more code for it. FPS-related code is brittle and takes a long time to test, since there are so many error/failure conditions to account for.

Sure, manually handling everything doesn't scale, but I'll deal with that when we're processing 1000s of payments instead of 10s.

Plus, I think it's pretty ridiculous that they won't give out the reason why it failed. Sure, I can write some more code to query the transaction status and error messages, but that means more code That's what I've found with FPS. Everything I do requires way more code than seems reasonable.

If the PayPal API can do even 1/2 of what it claims and is friendlier than FPS, I would drop FPS like a hot potato.

Reply on news.ycombinator.com