Authorize.net Gateway Errors are Hidden from Customer

Ecksters commented 6 years ago

Preconditions

Magento 2.2.0
PHP7
Using Cloudflare (possibly affecting the result?)

Steps to reproduce

Use Authorize.net Directpost Gateway
Input incorrect credit card details (like ZIP code)
Get generic error message

Expected result

Errors should be more specific on the front-end, at least as specific as what is shown on the backend.

Actual result

Backend properly shows the gateway error when you look at the canceled order, but frontend only gives: "An error occurred on the server. Please try to place the order again."

This isn't a security issue, as directpost sends the specific error message back to the client anyway, so there's no reason to obscure it from them, for example, the transact.dll page I get back is:

<html>
    <head>
        <script src="/cdn-cgi/apps/head/T7EtBsweFKe1xNvIw3WyPZwuLhQ.js"></script><script type="text/javascript">
//<![CDATA[
window.__mirage2 = {petok:"69f379d78c19a6555bff955b51606a795a185422-1511195322-1800"};
//]]>
</script>
<script type="text/javascript" src="https://ajax.cloudflare.com/cdn-cgi/scripts/0e574bed/cloudflare-static/mirage2.min.js"></script>
<script>
                    window.location="https://dressedinwhite.com/authorizenet/directpost_payment/redirect/x_invoice_num/1000020032/success/0/error_msg/Gateway error: The transaction has been declined because of an AVS mismatch. The address provided does not match billing address of cardholder./controller_action_name/directpost_payment/is_secure/1/";
                </script>
    </head>
    <body></body>
</html>

As you can see, the client already sees the error(but it isn't displayed to the user), which is "Gateway error: The transaction has been declined because of an AVS mismatch. The address provided does not match billing address of cardholder."

But when Magento 2 generates the error page, it's a generic error, like so:

<html>
    <head>
        <script src="/cdn-cgi/apps/head/T7EtBsweFKe1xNvIw3WyPZwuLhQ.js"></script><script>
                    var require = window.top.require;
            require(
                [
                    'jquery',
                    'Magento_Ui/js/model/messageList',
                    'mage/translate'
                ],
                function($, globalMessageList, $t) {
                    var parent = window.top;
                    $(parent).trigger('clearTimeout');
                    globalMessageList.addErrorMessage({
                        message: $t('An error occurred on the server. Please try to place the order again.')
                    });
                }
            );
                </script>
    </head>
    <body></body>
</html>

This is a massive issue, as any customer that has problems with checkout becomes highly likely to just give up due to being given no direction as to how to fix it.

Ecksters commented 6 years ago

I disabled CloudFlare's Mirage to make sure the modifications to the response weren't causing the problem, it now looks like this:

<html>
    <head>
        <script src="/cdn-cgi/apps/head/T7EtBsweFKe1xNvIw3WyPZwuLhQ.js"></script><script>
                    window.location="https://dressedinwhite.com/authorizenet/directpost_payment/redirect/x_invoice_num/1000020041/success/0/error_msg/Gateway error: This transaction has been declined./controller_action_name/directpost_payment/is_secure/1/";
                </script>
    </head>
    <body></body>
</html>

But still I only get a generic error on the front-end. I noticed that there appears to be code intended to detect the various errors, so I'm wondering why it's not working.

magento-engcom-team commented 6 years ago

@Ecksters, thank you for your report. We've created internal ticket(s) MAGETWO-84252 to track progress on the issue.

hfgoulding commented 6 years ago

Same issue / complaint. Any progress, patch available? I have three customer sites that are impacted. Your help is appreciated.

aeu commented 6 years ago

We are seeing this on Magento 2.1.12. Is there any progress on this? I'm in the same boat as @hfgoulding, I have a client site that is currently affected by this.

This is a serious bug. Based on the message the customer could very easily think that the site is not working and would not know to retry with a different card, which would mean the sale was lost.

Edit: We are not using Cloudflare, so you can remove that as a contributing factor. We are only using Redis.

bmzero commented 6 years ago

I have this issue on a new install of 2.2.3 as well.

When the customer enters an invalid credit card number, the response back from Authorize.Net explains that. However, Magento is displaying the generic message, making it look like there is a problem on the server. This message will result in the customer not correcting their card number and the site losing sales.

kfriend commented 6 years ago

I don't have much detail on the issue at hand, but the workaround I put into place:

Copy vendor/magento/module-payment/view/frontend/templates/transparent/iframe.phtml to app/design/frontend/[VENDOR]/[THEME]/Magento_Payment/templates/transparent/iframe.phtml.
Edit the new template's <?php elseif (isset($params['error_msg'])): ?> block, especially the message: $t('An error occurred on the server. Please try to place the order again.') line. This block checks if there is an error message, but never actually uses it. This may be by design, to prevent potentially sensitive information leakage, but I can't say that for sure ¯\_(ツ)_/¯. I changed the block to:

<?php elseif (isset($params['error_msg'])): ?>
    <?php
    $msg = $params['error_msg'];
    $msg = preg_replace('/^Gateway\serror:\s*/i', '', $msg);

    if ($msg === 'This transaction has been declined.') {
        $msg = 'The transaction was declined. Please review your payment details and try again.';
    }
    ?>
    var require = window.top.require;
    require(
        [
            'jquery',
            'Magento_Ui/js/model/messageList',
            'mage/translate',
            'Magento_Checkout/js/model/full-screen-loader'
        ],
        function($, globalMessageList, $t, fullScreenLoader) {
            var parent = window.top;
            $(parent).trigger('clearTimeout');
            fullScreenLoader.stopLoader();
            globalMessageList.addErrorMessage({
                message: $t('<?= $msg ?>')
            });
        }
    );

This block alters the error a bit, to make it more customer friendly.

bmzero commented 6 years ago

@kfriend, I think that's as good of a solution as any for right now.

Am I missing something? How could the default behavior (masking the "safe" error messages) create a good customer experience?

Ecksters commented 6 years ago

@kfriend Nice write-up of a decent patch, certainly better than leaving it as is.

This block checks if there is an error message, but never actually uses it. This may be by design, to prevent potentially sensitive information leakage, but I can't say that for sure ¯_(ツ)_/¯.

Like I said originally, if that was the intention, it was a very misguided one, since the error messages have to go through the client before we can see them anyway.

kfriend commented 6 years ago

From https://github.com/magento/magento2/issues/13172#issuecomment-357880599, it sounds like this is the expected behavior, and not one that's going to change. :head-desk:

maierb commented 6 years ago

@magento-engcom-team This is causing us to have to recommend against using Authorize.net why is this a good thing?

bmzero commented 6 years ago

I'm with @maierb. I don't get why anyone would want this. This has caused several issues with customers who abandon their transaction completely because they think the site is incapable of processing their transaction. When, in reality, they entered their card information incorrectly. Authorize.Net is a popular provider. This has to be affecting thousands upon thousands of transactions.

Ecksters commented 6 years ago

We've been forced to add text to our site telling customers to try to checkout with PayPal if they have issues, since at least PayPal will give them proper error messages..

AirmanAJK commented 6 years ago

Even worse, the message only shows up above the payment method for a few short seconds. So if they're scrolled down on a laptop, they don't even see it.

How this payment method doesn't have an option to "Allow success even on failed authorization" is beyond me. WE STILL WANT THE ORDER! We've had multiple people go to a competitor because of this clunky, lazy, unstable payment method.

kfriend commented 6 years ago

@maierb @bmzero @Ecksters @aeu @hfgoulding

I doubt Magento is ever going to fix this. I've come to that conclusion given the following info and thoughts:

The complete lack of movement or interest in this issue from Magento, even when this has been ongoing for some time. Amazing, given this deals with one of the most crucial aspects of an ecommerce site.
Authorize.net's deprecation of this payment method, some time ago. Which means Magento is even less interested in fixing it, even though it's still used.
Magento's relationship with Paypal, i.e. they'd like you to use Paypal instead of Authroize.net.

There's also no info on when Magento will implement Accept.js, compounding the need to fix this issue.

We've switched to use ParadoxLabs's Authorize.net CIM extension, which implements Accept.js. We've had outstanding success with it, compared to Magento's build in Authorize.net support. It gives proper error messages (which don't vanish), CC card validation, etc.

AirmanAJK commented 6 years ago

I've made several small changes to deal with the issue:

When the order times out, we mention that "we have your order" instead of just dropping them on an empty cart page with no message at all.
When there is an error message, I used a modal UI alert so they will actually see the message and have a chance to acknowledge it. Otherwise, if they aren't scrolled up, they wouldn't even see the 5 second message of "Server error" at the top of the page. I also give a detailed message of what they can do.
The failed attempts are actually put into the exception log, instead of erroring out without leaving a trace. They fixed this in a later version of Magento, but how it wasn't there to begin with is crazy.

I still can't believe how little effort was put into user experience for this payment method. Most of our payments are CC direct post, and if it doesn't go perfectly, we very likely lost the order.

inkobject commented 6 years ago

Just had customer yell at me for attempting 4 transactions, all of which failed due to an AVS mismatch, which he believed were charged.

If there is no solution to this on the horizon for base Magento 2, is there an extension or other solution I can apply that gives the customer a better experience when it come to Authorize.net responses?

razorgamez commented 6 years ago

We've been seeing the same issue, as well as if you go back into your shopping cart, the cart is empty (if you are not logged into an account). Anyone else experience it? @kfriend can you possibly share a screenshot of how it handles avs mismatch errors etc?

clikit101 commented 6 years ago

@bmzero Did you ever find a solution for Magento 2.2.3 or did you only resort to Kfriend's patch? I am looking at ParadoxLabs's Authorize.net CIM extension and wondering if that would not be the ultimate solution

bmzero commented 6 years ago

@clikit101 I did implement the change from Kfriend, but there are still big issues, especially on mobile as the page will obviously not scroll up to display the error. We do still have occasional issues where customers call in to complain that the website will not process their order only to find out that it was an AVS mismatch or something that would have displayed in the error box.

This is a ridiculous situation. I don't understand how a payment system as popular as Authorize could be so crippled by Magento. Magento needs to display the errors near the Place Order button.

joshuaadickerson commented 6 years ago

@clikit101 I'd recommend ParadoxLab's module.

AirmanAJK commented 6 years ago

FYI, you can allow AVS mismatches in your Authorize.NET configuration as well as other relaxations on what must match or be flagged as fraud instead of failing. Obviously, you will need to be more vigilant about fraudalent orders if you do this.

clikit101 commented 6 years ago

@bmzero You are so correct in your affirmation. It is plainly stupid to show an error message at a spot where you cannot even see it. @joshuaadickerson Does ParadoxLab's module solve the issue of where the message is shown to front users and give details on AVS mismatches to assess the status of the orders adequately? @AirmanAJK I know about the configuration but the problem is definitely fraudulent orders and for Canada it is not the greatest.

AirmanAJK commented 6 years ago

@clikit101 If you need, I can share my code snippet to display the error message as a modal UI alert. It uses the built in Magento components, so it's not much code. Here's a screenshot: payment alert

You can see the original error message lurking in the background.

clikit101 commented 6 years ago

@AirmanAJK It would definitely help if you could share your code snippet to display the error as a modal UI alert. At least customers would see the message and we could give them the opportunity to call us in case of problems.

clikit101 commented 6 years ago

@AirmanAJK . Any chance you can share your code snippet?

seanscott49 commented 6 years ago

Same problem on 2.2.5. Our call center got blocked by mod_security for 3 declined transactions because they didn't know it was declined. Calls me to say server down, which it wasn't. Investigated the issue, and the card was declined multiple times and only the call center was blocked for 30 mins. Then today, errors again. Dive in and it was AVS mismatched. By not having the reason for the decline come up as a modal and the specific reason why it's going to create a HUGE problem for me when the holiday rolls in. It also finally explains all of the abandoned carts since we migrated to M2.

@AirmanAJK , the code snippet would be extremely helpful.

clish1 commented 6 years ago

Here is a link to the solution. I have not completed it yet. https://devdocs.magento.com/guides/v2.2/payments-integrations/payment-gateway/error-code-mapper.html

hfgoulding commented 6 years ago

This is great news, I would appreciate it when you complete the solution.

thanks

Hugh

On 08/31/2018 07:27 PM, clish1 wrote:

Here is a link to the solution. I have not completed it yet. https://devdocs.magento.com/guides/v2.2/payments-integrations/payment-gateway/error-code-mapper.html

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/magento/magento2/issues/12366#issuecomment-417819224, or mute the thread https://github.com/notifications/unsubscribe-auth/ARX-ELocK5HMP0KMn2-ZLxV6HvBxklUlks5uWdSCgaJpZM4Qki6U.

--

ParagBhargav commented 6 years ago

@AirmanAJK Can you please share the code for display the error message in the popup? It will really help us.

jpbazinet commented 5 years ago

Has anything been done about this yet? I'm still having this same problem...

clish1 commented 5 years ago

I am not sure, but I have switched to Braintree, which is integrated into Magento and even that provides terrible error code communication. Magento provides poor support on these things.

From: jpbazinet notifications@github.com To: magento/magento2 magento2@noreply.github.com Cc: clish1 gclisham@southco.com, Comment comment@noreply.github.com Date: 10/24/2019 09:48 PM Subject: Re: [magento/magento2] Authorize.net Gateway Errors are Hidden from Customer (#12366)

[EXTERNAL EMAIL] Has anything been done about this yet? I'm still having this same problem... ? You are receiving this because you commented. Reply to this email directly, view it on GitHub, or unsubscribe.

CONFIDENTIALITY NOTICE: The information contained in this electronic mail and its attachments is privileged and confidential information and is intended for the use of the individual or entity named above and others who have been specifically authorized to receive it. If you are not the intended recipient, you are hereby notified that any use by you or any dissemination, distribution or copying of this communication by you is strictly prohibited. If you have received this in error, please delete it and notify us immediately. Thank You.

m2-assistant[bot] commented 4 years ago

Hi @VigneshVenkatesan154. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

[ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
Details
If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.
[ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.
[ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.
[ ] 4. Verify that the issue is reproducible on 2.4-develop branch
Details
- Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
[ ] 5. Add label Issue: Confirmed once verification is complete.
[ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

m2-assistant[bot] commented 4 years ago

Hi @engcom-Delta. Thank you for working on this issue. In order to make sure that issue has enough information and ready for development, please read and check the following instruction: :point_down:

[ ] 1. Verify that issue has all the required information. (Preconditions, Steps to reproduce, Expected result, Actual result).
Details
If the issue has a valid description, the label Issue: Format is valid will be added to the issue automatically. Please, edit issue description if needed, until label Issue: Format is valid appears.
[ ] 2. Verify that issue has a meaningful description and provides enough information to reproduce the issue. If the report is valid, add Issue: Clear Description label to the issue by yourself.
[ ] 3. Add Component: XXXXX label(s) to the ticket, indicating the components it may be related to.
[ ] 4. Verify that the issue is reproducible on 2.4-develop branch
Details
- Add the comment @magento give me 2.4-develop instance to deploy test instance on Magento infrastructure.
- If the issue is reproducible on 2.4-develop branch, please, add the label Reproduced on 2.4.x.
- If the issue is not reproducible, add your comment that issue is not reproducible and close the issue and stop verification process here!
[ ] 5. Add label Issue: Confirmed once verification is complete.
[ ] 6. Make sure that automatic system confirms that report has been added to the backlog.

engcom-Delta commented 4 years ago

@Ecksters starting from 2.4.0 release, code related to this payment was removed from Magento code-base

With this release, the Authorize.Net, eWay, CyberSource, and Worldpay payment method integrations have been removed from core code. Merchants should migrate to the official extensions that are available on the Magento Marketplace.

If you experience issue on the latest composer version 2.4.1, please refer to to the corresponding extension owners(support) on the Magento Market place page

magento / magento2