Canada AVS Issues
-
I have recently started to see some AVS related issues with my Canada customers (although not all).
In WC Orders I see the order is failed with messages added such as:
“GoDaddy Payments Payment Failed (AVS has a NO_MATCH result) Order status changed from Pending payment to Failed.”
“GoDaddy Payments Payment Failed (AVS has a NO_MATCH result)”Yet when I look online in my GDP Dashboard – the transaction doesn’t appear at all. If the Issuer Bank declined the transaction, then how come it doesn’t appear in the dashboard as a decline? Seems to imply the plugin is doing something on it’s own. By contrast, a pure insufficient funds decline shows up in the dashboard and shows up every time there is a decline.
Makes me suspicious about how/why these AVS failures are occurring with nothing in the GDP dashboard just “AVS no match” notes in WC.
The page I need help with: [log in to see the link]
-
Might be related but I have turned on debugging. When doing so I see a few “fatal error” logs an example below (slight obfuscation of full paths). Doesn’t seem to be at the same time as the failed AVS order.
2023-11-28T04:23:11+00:00 CRITICAL Uncaught Error: Call to a member function get_payment_method() on bool in /home/namgbr/public_html/wp-content/plugins/godaddy-payments/src/Gateways/PayInPersonGateway.php:150 Stack trace: #0 /public_html/wp-includes/class-wp-hook.php(324): GoDaddy\WooCommerce\Poynt\Gateways\PayInPersonGateway->maybe_render_held_order_received_text('Thank you. Your...', false) #1 /public_html/wp-includes/plugin.php(205): WP_Hook->apply_filters('Thank you. Your...', Array) #2 /public_html/wp-content/plugins/woocommerce/templates/checkout/order-received.php(34): apply_filters('woocommerce_tha...', 'Thank you. Your...', false) #3 /public_html/wp-content/plugins/woocommerce/includes/wc-core-functions.php(345): include('/home/namgbr/pu...') #4 /public_html/wp-content/plugins/woocommerce/includes/shortcodes/class-wc-shortcode-checkout.php(312): wc_get_template('checkout/order-...', Array) #5 /public_html/wp-content/plugins/woocommerce/includes/shortcodes/class-w in /home/namgbr/public_html/wp-content/plugins/godaddy-payments/src/Gateways/PayInPersonGateway.php on line 150
WC 8.2.1
WP 6.4.1
PHP 7.4.33
GDP 1.6.2Update: It’s done it again. I do have a debug log but have now turned off GDP and replaced it with another processor.
Interestingly the WC order notes now show “This order address is Validated” followed by “GoDaddy Payments Payment Failed (AVS has a NO_MATCH result)”
As before there’s zero trace of this transaction in the online transactions dashboard at godaddy.com – bizarre but seems you have some issues going on somewhere.
Hey there,
Thanks for reaching out about our GoDaddy Payments plugin. I am happy to help clarify this information for you.
The GoDaddy Payments system uses an Address Validation Service (AVS) to check both postal code and billing address for the card being used. This is an enhanced security measure to help curb fraudulent charges that then become Chargebacks from our merchants’ GoDaddy Payments accounts. This change was implemented in mid-September of this year when seeing that using only the Postal Code was creating a spike in Chargeback situations for our merchants.
This means that your customers will need to use the exact Billing Address that their bank has on file for their credit card they are using. If that AVS does not entirely match the bank’s information, then the transaction will stop there, and in the GoDaddy Payments logs you will see their transaction show “NO_MATCH”. Most of the time after an additional run of the correct Billing information, the order will process. However, if you see any orders that get “stuck” in Pending Payment (or moved to Cancelled/Failed), that is a sign the customer was not able to match the Billing information that is on file at their bank.
We see this particularly with customers from countries where postal codes may include spaces or dashes, as even though as customers we may put in those spaces, when the bank put the info into their system originally, they may have removed the space or put in a dash instead, which now means that the Billing Address must match. Likewise, “Ave.” is not the same as Ave or Avenue. Some cards and some banks are more particular than others, which also comes into play with these AVS checks. A Visa from one bank may let “St” apply for Street, but a MasterCard at another bank may require exact characters.
On your end as a merchant, when the AVS check fails, the gateway plugin logs the failure, but there will be no transaction in your GoDaddy Payments account side because no transaction is actually created – the security filter stops the transaction process immediately when AVS fails.
As you said, the Order Notes you are now seeing are interesting – that was an improvement just released this week, so that would be why this is a new notice you are now seeing. However, I agree that the wording there seems a bit contrary, so I reached out to our engineering team to see whether the “valid – no valid” feel there was intended, or if that can be modified to be clearer. : )
Would you please let me know if that is helpful information, and what further questions you have?
All the Best,
Kari | SkyVerge Support TeamThanks. After the space and dash in postcode debacle I went through this is the straw that breaks the camel’s back and I am uninstalling the plugin and taking my processing elsewhere.
This is the most bizarre implementation of AVS I ever heard of and I worked for a major payment system/brand for 30 years!
I figured I add context for thought.
If the street number plus post code matches, this is usually enough to confirm since street number + 5-4 ZIP is actually all that is needed as is street number + UK post code.
If you ship stuff, chances are you may use an address verification service to get the EXACT correct address e.g. as we do using the USPS API. It ensures delivery of items to use what USPS says the address is not what the cardholder *thinks* the address is.
Making AVE not match AV or AVE. or Avenue is simply creating declines for no reason that actually adds any value.
It should be possible for a Merchant to determine what’s OK. A partial AVS where the ZIP/Postcode matches (AVS Response Z, or W for example) might be “good enough” for a merchant to want to accept. You provide no options.
As noted, anyone that uses a verified address service, will experience lots more AVS declines because of your exact match requirement, and seriously confused customers who have no idea that they must remember how the address is on file with the bank which could vary slightly between banks/issuers.
Hey there,
Thanks for circling back on this with more details.
The feature that you are requesting has actually been discussed within our engineering team, as to whether it would be possible to have the merchants select the “level” of AVS that they would prefer to use on their website. I believe they have been looking into whether that would be possible with our gateway based on the GoDaddy Payments requirements.
I feel like you have presented a very good position for why this would be an important feature for our gateway plugin to have, and I am going to pass this on to the team for their further consideration. As a support team, we definitely feel some of the same pain points you feel when we receive these kinds of concerns and requests, and I want you to know our whole team appreciates receiving suggestions like these that can improve the functionality of our products. I am happy to bring to light this issue with potential conflicts with AVS/Shipping plugins, as it is an extremely valid point to consider!
Thank you again for providing this information. Do you have any further questions for us at this time?
All the Best,
KariThanks for the update. No other questions.
As additional info:
We use https://elextensions.com/knowledge-base/set-up-elex-address-validation-google-address-autocomplete-plugin-for-woocommerce/ and have address verification set to “forced” so I get back what USPS says the address is and proper address abbreviations like BLVD instead of Boulevard. So unless a card issuer also normalizes addresses to USPS official data that customer is likely to constantly see declined/AVS failed.
We are a car club, so we don’t actually ship anything of “value”. In 3 years we have seen zero fraud, so transactions being declined for AVS issues just creates problems and confusion. I could happily operate without AVS and not see any issues. Sure that’s likely unusual/edge case but its true/valid for me. ??
I don’t think this September change was communicated well and the change log certainly doesn’t explain what you described above as to how impactful this could be.
Because I had 2 club members caught in the loop of being unable to match their address I had to give them a payment link to get around the issue. While the number of issues is small, trying to solve these issues is hugely time consuming. So it’s easier for me in the longer term to just pay for higher processing costs and not have this potential issue with a customer (member of the club) which is why I had to switch back to our prior processor/gateway.
Hey there,
Thank you so much for this additional information. I have already passed on your previous thoughts to our engineering team, and will also attach this information as well. I truly appreciate your candor and your feedback on this issue. We take to heart concerns like this, so please know that your feedback will be reviewed by our developers and product team.
I am so sorry to hear that you will need to move to another gateway, yet I can understand that necessity at this time. That said, I am happy to update you if I hear back that the AVS selection functionality gets added to the plugin, or other modifications are made that will improve your use case for our plugin.
Thank you again,
Kari
Sorry, one additional thought (I used to work in payments) ??
You should also factor in CVC2/CVV2 verification and result. If you get a post code match, but not street address, but the CVC2 match is a Y then again that might be enough for a merchant to want to accept. Sure the CVC2 isn’t the greatest security element in the world but combined with other factors can be useful.
Hey there,
Thanks for the extra thought! We appreciate your input very much and I will share this additional consideration with the team. I do believe there is a separate CVC/CVV check that gets run as well, I recall seeing that check in the logs when assisting customers before. However, if not, we can certainly take that method into consideration as well!
Happy Holidays!
Kind Regards,
KariHopefully the last thought. ??
As I am trying out another processing platform, here’s an example of giving options to merchants to choose how to handle AVS responses. So, something like this would be way more useful than the arbitrary/absolute stance your implementation uses.
Hey there,
Amber here, filling in for Kari. Thank you for sending over a screenshot of a method that you like for filling out those details. I will definitely pass this along to our team.
Is there anything else I can assist you with?
All the best,
Amber
- The topic ‘Canada AVS Issues’ is closed to new replies.