Authorize.net declined transactions go in as failed- which may/may not be a bug

[robinsowell]

Cartthrob_authorize_net.php:charge (175-176) where the code treats anything that is not successful as a failure:

            if (!$response->isSuccessful()) {
                return $this->fail($response->getMessage());
            }

CT does have the framework for a 'declined' response, but it looks like anything that isn't a success in authorize.net gets recorded as 'failed'. Which... is not necessarily a bug, but if we can catch a 'declined' it would be nice.

[TomJaeger]

Do you know version of CT?

[jsibre]

It's 9.0.0-b2
Sorry for the late response - I just decided to check the status of this issue, and saw your query.

[jsibre]

Edited to add details around declined, and how the code below doesn't address it.

I've bumped into this again. I noticed that it wasn't only affecting "Declined" transactions, but also "Processing" transactions (where they haven't failed, but they need to be manually reviewed due to, E.g., Fraud Detection filters.

This causes a real problem because it leads to messages to the user that look like error messages, and leaves the person on the checkout form, when if fact the transaction is in pending state. So they'll reasonably think that their transaction has not been completed. If they try again, they could end up being double-charged, triple-charged, etc., when a person reviews and approves the transactions..

I don't know if this is the "right" fix, but I've tried modifying the referenced file's charge() function so that it exits via this logic:

        if ($response->isSuccessful()) {
            return $this->authorize($response->getTransactionReference());
        } elseif ($response->isPending()) {
            return $this->processing($response->getTransactionReference());
        } else {
            return $this->fail($response->getMessage());
        }

I've done a little testing on this, and so far it behaves as I'd expect for "hold for review" and "approved". It doesn't address "declined" (RESPONSE_CODE_DECLINED). Of course there are a LOT of permutations possible from Authorize.net and it's resopnses, but I do think that they all result in a response with a code of 1, 2, 3 or 4.

Here are the response codes.
1 -- Approved -> isSuccessful() == true. Should be authorize()d.
2 -- Declined -> neither isSuccessful() or isPending(). Should be marked as Declined, based on presence of RESPONSE_CODE_DECLINED, but I don't see anything covering that case. Maybe that's a type of fail(), but with more detail/context so that it can be statused properly.
3 -- Error -> neither isSuccessful() or isPending(). Should be fail()ed.
4 -- Held for Review -> isPending() == true. Should be marked processing().