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.