Order status of (None), but payment successfully received?

[Shaun Dishman]

Hi folks,

We launched a new storefront for a client last week, and are seeing
some intermittent weird behavior. We are using Django 1.3 with
Satchmo 0.9.2, and we use Authorize.NET as the payment module.

For a small percentage of the orders, they list a status of
"None" (which I always thought meant that the order was still pending,
and was not completed) - but if I examine the order details, I see a
successful payment recorded with a valid Authorize.NET transaction
ID. How is it possible to receive payment but not finish the order?

I don't have a good idea of what the end-users are doing to cause this
behavior, but I was hoping someone here may have seen this before.
What's happening is that customers are getting confused and somehow
starting a second order, which they pay for and successfully complete,
but then they've been double-charged so our client is having to issue
refunds.

Thanks in advance for any help you can provide.


-- Shaun

[GuyBrush]

Hi
I had similar problems which got fixed by installing memcached but I
never had a double-charging problem.
Do you have memcached setup?

I'm having some of those problems again and I'll be investigating &
testing with a 1 cent test product.
Let me know if you find a fix for this problem.

Thanks
Orion Vianna

[hynekcer]

It should be easy to catch this problem. Order balance is verified
exactly to cents and if there is any difference, the property
'order.paid_in_full' is evaluated false.

Use this simple patch for logging: http://pastebin.com/HKWbCZBR
You can also select well known option "Verbose logs" for payments in
livesettings ("Add extensive logs during post." EXTRA_LOGGING)

Then use filtering in the log what is not paid exactly.
grep paid_in_full satchmo.log

If you confirm very small balances in the log and Chris will agree,
the method '_paid_in_full' can be simply changed in Satchmo.
I think that payments rounded up to whole number can be silently
accepted for some currencies, namely rounding up, but I do not know
and really I do not want to suggest anything about payments.

Hynek

[Shaun Dishman]

Well, the problem disappeared shortly after I posted, and then
reappeared three weeks later. After investigating the second
occurrence, I discovered that the problem was related to an exception
being caused in a listener we had registered against the
"order_completed" signal. So the candidate would finish their order,
get successfully charged by Auth.NET, the order_completed signal would
fire, and our code would throw an error, which apparently was
preventing the Order status from being updated.

I figured I would post that just in case someone comes along behind
someday with the same issue. Thanks for the help!


-- Shaun

[hynekcer]

Thanks. Good detective work.

We should use the method "send_robust instead" instead of "send" in
"Order.order_success".

Django docs:
"send_robust() catches all errors derived from Python's Exception
class, and ensures all receivers are notified of the signal. If an
error occurs, the error instance is returned in the tuple pair for the
receiver that raised the error."

ALL developers:
Please Do you know more signals which need "send_robust" instead of
"send"?

Please, not too much signals to be changed, only the most important
because
a) It is more complicated - it requires to solve error handling for
them.
b) For some signals it is better to normally raise exception if one
listener fails,
e.g. for satchmo_price_query.
(It could be more expensive to sell one hour with bad price than to
stop it for one hour.)

Shaun,
Good detective work, but how it is possible that you did not note any
html 500 errors in web server log at the time of payment?

You probably mean "order_success". Hm, I do not know any
"order_completed".

-- Hynek