Comment 7 for bug 632361

On Mon, Nov 8, 2010 at 1:28 PM, Matthew Paul Thomas <email address hidden> wrote:
>> If you think it would be better to provide exact errors to the
> purchaser
>
> Providing exact errors would be better if (a) knowing more would make
> people more forgiving (for example, if it wasn't our fault), or (b) it
> would help people choose what to do next. So, would either be true here?

Looking through the code, there seems to be one failure for which (a)
and (b) will be true: when the user goes through the Payments ui
without issue, but when the SCA gets a notification and checks the
status of the payment it is not authorised. This is (3) below. All
other possible failures are failures on from us (well, SSO, Launchpad,
connection to payments etc., in some way, our fault) for which we
can't give any better recommendation than "try again later" afaik.

So, a full list:

These first two were only relevant during the restricted beta:
1) Error while verifying whether user is allowed to [App name] (ie. an
error while using SSO api)
2) Software purchases are not yet publically available. (ie. only
possible if a config switch is on)

This is the relevant one for which we do need feedback:
3) Payment status returned by payment service was [payment status]
(ie. payment status returned by payments API is something other than
AUTHORISED)

And the rest which fall into the "Try again later" category:
4) Error while checking or creating a LP person: [user_name] (ie. an
error while using LP API)
5) Unable to create payment: [first line of payment exception] (ie. an
error when using payments api)
6) Unable to create Launchpad subscription: [first line of error] (ie.
an error while using LP API)
7) Unable to capture payment: [first line of error] (ie. error during
call to payment API capture_payment)

Hope that helps.

> Would the suggested action differ at all depending on the error? In "try
> again later", how much later?
>