logo
Welcome to our new AbleCommerce forums. As a guest, you may view the information here. To post to this forum, you must have a registered account with us, either as a new user evaluating AbleCommerce or an existing user of the application. For all questions related to the older version of Gold and earlier, please go to forums.ablecommerce.com. Please use your AbleCommerce username and password to Login. Forums Registration.

Notification

Icon
Error

Options
Go to last post Go to first unread
Joe Payne @ AbleMods LLC  
#1 Posted : Friday, May 15, 2020 7:33:40 AM(UTC)
Joe Payne @ AbleMods LLC

Rank: Advanced Member

Groups: Developers
Joined: 11/9/2018(UTC)
Posts: 92

Thanks: 11 times
Was thanked: 5 time(s) in 5 post(s)
I was able to confirm that AuthNet CIM payments made with a stored card profile do not get passed through any AVS/CVV checks that are configured in the Authorize.Net merchant settings.

The problem is two-fold:

First:
In order to get AuthNet to send stored profile payments through their AVS security checks (their Fraud Detection Suite), you must pass those values in the request.ExtraOptions field of the API data model. And the merchant must make additional settings changes to mark the address and postal code fields as 'required' in the AuthNet payment form within the merchant settings. Only then will AuthNet provide a valid AVS response on charges made via a stored payment profile.

Able code is not doing that.

This is a serious flaw because of first-time customers. Any first-time customer who chooses to store the card during checkout is able to completely bypass all AVS checks configured by the merchant. The merchant has no clue if the supplied billing address is valid. And I'm willing to bet the vast majority of merchants using CIM in Able have no idea their AVS checks are not happening when paid with a stored card profile.


Second:
When the shopper chooses 'save card information' during checkout, the Able design is to create the CIM profile, create the payment profile, and then use the stored payment profile as payment. If the routines were designed to run the charge as a regular DoAuthorize() PRIOR TO creating the stored profile, the usual AVS/CVV checks would happen. This would go a long way to reducing fraud for the merchant as the initial payment details could not be stored until they passed AVS/CVV validation. Not ideal of course because the shopper could return later and use the now-stored payment profile with a different address. But it's certainly better than zero AVS checks which is what we have right now.

I was able to modify my client's AuthNet CIM routines to do the above and it's now working properly. You can read more about the solution here: https://community.develo...41/highlight/true#M17385
thanks 1 user thanked Joe Payne @ AbleMods LLC for this useful post.
ray22901031 on 5/15/2020(UTC)

Wanna join the discussion?! Login to your AbleCommerce Forums forum account. Forums Registration.

shari  
#2 Posted : Friday, May 15, 2020 12:23:28 PM(UTC)
shari

Rank: Advanced Member

Groups: Admin, Developers, Registered, HelpDesk, Authorized User
Joined: 10/5/2018(UTC)
Posts: 95

Was thanked: 10 time(s) in 10 post(s)
Thanks for pointing it out.
We will be looking into this improvement.

Edited by user Friday, May 15, 2020 12:53:16 PM(UTC)  | Reason: Not specified

Joe Payne @ AbleMods LLC  
#3 Posted : Friday, May 15, 2020 12:24:38 PM(UTC)
Joe Payne @ AbleMods LLC

Rank: Advanced Member

Groups: Developers
Joined: 11/9/2018(UTC)
Posts: 92

Thanks: 11 times
Was thanked: 5 time(s) in 5 post(s)
Also need to address the CVV issue. Able does not prompt for CVV when paying with a stored card profile. Thus any AuthNet transaction paid with a stored card will not receive any validation of CVV because no CVV is being passed.
thanks 1 user thanked Joe Payne @ AbleMods LLC for this useful post.
ray22901031 on 5/15/2020(UTC)
ray22901031  
#4 Posted : Friday, May 15, 2020 3:31:47 PM(UTC)
ray22901031

Rank: Advanced Member

Groups: Authorized User, Developers
Joined: 2/17/2019(UTC)
Posts: 171

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
Hey Joe,

First I'm extremely grateful that you were able to identify this problem, I'm also grateful that I'm not launching in the next couple of months as situations like this could decrease my sales.

I want to take this one step further, since I have been reliant on Authorize.net for the last 15 years, and we're looking to have a custom-built Signify plug-in. Authorize.net has a very tight integration with Signify, which we have been using for many years for protection against credit card fraud. Authorize.net integrates with Signify to pass the AVS information, if this information is not being passed, Signify will decline protection on every single order.

https://www.signifyd.com...es/manual/authorize-net/

In other words, as a merchant, I cannot ship any orders without assuming responsibility for fraudulent chargebacks. This is not very good for sales. Hopefully this issue will be rectify shortly and rapidly.

I am putting in my two cents because as a merchant, using this software and about to launch soon, this is a very serious issue and needs serious consideration.

Many thanks,
-Ray

ray22901031  
#5 Posted : Friday, May 15, 2020 3:51:17 PM(UTC)
ray22901031

Rank: Advanced Member

Groups: Authorized User, Developers
Joined: 2/17/2019(UTC)
Posts: 171

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
Hey Joe,

A follow-up question if I can, Authorize.net has the ability to store the credit card information on their system, is this issue occurring on credit card information being stored on their end, or is it just credit card information on Ablecommerce's end, or both?

PS: not asking for CVV information on new purchases is a recipe for disaster if someone hacks an account, this is why the CVV under credit card guidelines should never be stored in the first place, and this is why it needs to be constantly reentered by the legit credit card holder on new purchases. - Just in case people were not aware of this.

Again many thanks,
-Ray
ray22901031  
#6 Posted : Saturday, May 16, 2020 5:59:57 PM(UTC)
ray22901031

Rank: Advanced Member

Groups: Authorized User, Developers
Joined: 2/17/2019(UTC)
Posts: 171

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
I am assuming that you can turn off the save credit card information, since I don't understand why somebody would use authorize.net and not use their token service and store that information with them?

Will turning off the save credit card information at least fix this problem?
Joe Payne @ AbleMods LLC  
#7 Posted : Saturday, May 16, 2020 6:06:50 PM(UTC)
Joe Payne @ AbleMods LLC

Rank: Advanced Member

Groups: Developers
Joined: 11/9/2018(UTC)
Posts: 92

Thanks: 11 times
Was thanked: 5 time(s) in 5 post(s)
Sure

The customers ability to securely store a credit card with the merchant is quite popular and definitely increases sales.
ray22901031  
#8 Posted : Saturday, May 16, 2020 6:10:37 PM(UTC)
ray22901031

Rank: Advanced Member

Groups: Authorized User, Developers
Joined: 2/17/2019(UTC)
Posts: 171

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
Absolutely and completely agree, but the full version of authorize.net allows you to store this information on their servers by using a token, and that token then communicates with the bank. Please don't tell me Ablecommerce doesn't support the full version of authorize.net?
Joe Payne @ AbleMods LLC  
#9 Posted : Saturday, May 16, 2020 6:15:31 PM(UTC)
Joe Payne @ AbleMods LLC

Rank: Advanced Member

Groups: Developers
Joined: 11/9/2018(UTC)
Posts: 92

Thanks: 11 times
Was thanked: 5 time(s) in 5 post(s)
What you’re describing is known as CIM and that’s what Able supports via their CIM payment gateway. Able also supports standard card transactions through a separate legacy payment gateway.

Able additionally supports storing carD details locally in encrypted format in the SQL database. Most merchants don’t like that idea so the feature is rarely used.
ray22901031  
#10 Posted : Saturday, May 16, 2020 6:33:05 PM(UTC)
ray22901031

Rank: Advanced Member

Groups: Authorized User, Developers
Joined: 2/17/2019(UTC)
Posts: 171

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
Correct, but I am confused, I understand that there's a bug in the software that need to be addressed with the CVV, but why would you choose to store the credit card information locally, I understand it's encrypted, but as far as sales are concerned, I can get more mileage telling a customer that we do not store credit card information locally but rather use the information that stored at their banks.

This way in the event if I'm ever hacked, and I have been hacked before even with encrypted credit cards, I don't have to worry about this. Obviously, if somebody was not using authorize.net CIM, which I believe is the only one at this point that offers the token service, storing credit cards locally would be the only option.

The CVV bug was a grave oversight and the fact that you were able to find it was extraordinary, but I am hoping that they will understand that this is not an improvement but rather a bug in their system. If not I am very sure that other people who support the software will let them know that this is not an improvement but a bug that needs to be fixed.

I will say this: as you know have expressed this on multiple occasions regarding my concerns about Ablecommerce, not that you can name one piece of software that doesn't have bugs, but it's their response to users and developers that concerns me. That being said, despite the many bugs, it has yet to rise to the level of Magento 2 where it cannot even clone a product without going through a loop that creates over 100,000 bogus entries.

I have already wasted a good solid year with Magento, and I am hoping if not praying that this does not occur with Ablecommerce, but time will tell. Hopefully others will join in to make sure that these bugs are fixed.

Joe Payne @ AbleMods LLC  
#11 Posted : Saturday, May 16, 2020 7:35:51 PM(UTC)
Joe Payne @ AbleMods LLC

Rank: Advanced Member

Groups: Developers
Joined: 11/9/2018(UTC)
Posts: 92

Thanks: 11 times
Was thanked: 5 time(s) in 5 post(s)
CIM costs extra per month. And like I said, merchants rarely use self storage any more.

Not everyone has your experiences with customers. Some industries thrive better with repeat business because of stored card profiles.
mazhar  
#12 Posted : Wednesday, May 20, 2020 9:55:25 AM(UTC)
mazhar

Rank: Administration

Groups: Admin, Administrators, HelpDesk, System, Authorized User, Developers, Registered
Joined: 10/5/2018(UTC)
Posts: 64

Thanks: 5 times
Was thanked: 8 time(s) in 7 post(s)
Quote:

Will turning off the save credit card information at least fix this problem?


The context of this thread is specific to Authorize.NET CIM and payment profiles that are maintained by Authorize.NET. If you have Authorize.NET CIM configured, there is an option in Store -> Settings under Checkout Settings section to give customer ability to store cards. This thread applies to that particular setting. Once you have it enabled, customer can choose to save their card upon payment. This will result in a profile creation in Authorize.NET which can then use later for more payments instead of entering the card details again.

If you are not using Authorize.NET CIM and making use of Standard Authorize.NET this doesn't apply on you. If you are using Authorize.NET CIM then you can turn off the above setting and it will fix the issues mentioned by Joe.
ray22901031  
#13 Posted : Thursday, May 21, 2020 11:52:14 AM(UTC)
ray22901031

Rank: Advanced Member

Groups: Authorized User, Developers
Joined: 2/17/2019(UTC)
Posts: 171

Thanks: 2 times
Was thanked: 2 time(s) in 2 post(s)
Mazhar,

First thank you for your reply, but the main issue that has been expressed by Joe has not been addressed. Are you able to reproduce the issue that he stated?

If ablecommerce has an issue passing CVV information, this is extremely problematic. This is the only issue that needs to be addressed at this point.

Thank you,
-Ray
mazhar  
#14 Posted : Friday, May 22, 2020 4:56:50 AM(UTC)
mazhar

Rank: Administration

Groups: Admin, Administrators, HelpDesk, System, Authorized User, Developers, Registered
Joined: 10/5/2018(UTC)
Posts: 64

Thanks: 5 times
Was thanked: 8 time(s) in 7 post(s)
Originally Posted by: Joe Payne @ AbleMods LLC Go to Quoted Post
I was able to confirm that AuthNet CIM payments made with a stored card profile do not get passed through any AVS/CVV checks that are configured in the Authorize.Net merchant settings.

The problem is two-fold:

First:
In order to get AuthNet to send stored profile payments through their AVS security checks (their Fraud Detection Suite), you must pass those values in the request.ExtraOptions field of the API data model. And the merchant must make additional settings changes to mark the address and postal code fields as 'required' in the AuthNet payment form within the merchant settings. Only then will AuthNet provide a valid AVS response on charges made via a stored payment profile.

Able code is not doing that.

This is a serious flaw because of first-time customers. Any first-time customer who chooses to store the card during checkout is able to completely bypass all AVS checks configured by the merchant. The merchant has no clue if the supplied billing address is valid. And I'm willing to bet the vast majority of merchants using CIM in Able have no idea their AVS checks are not happening when paid with a stored card profile.


Second:
When the shopper chooses 'save card information' during checkout, the Able design is to create the CIM profile, create the payment profile, and then use the stored payment profile as payment. If the routines were designed to run the charge as a regular DoAuthorize() PRIOR TO creating the stored profile, the usual AVS/CVV checks would happen. This would go a long way to reducing fraud for the merchant as the initial payment details could not be stored until they passed AVS/CVV validation. Not ideal of course because the shopper could return later and use the now-stored payment profile with a different address. But it's certainly better than zero AVS checks which is what we have right now.

I was able to modify my client's AuthNet CIM routines to do the above and it's now working properly. You can read more about the solution here: https://community.develo...41/highlight/true#M17385


Hi Joe, I went through the details you posted and reviewed our codes in detail. I think we missed the bit about CVV/AVS not triggering if customer choose to save card for the first time. We are using stored profiles in recurring billing where auto generated orders are automatically processed without intervention from customer to enter CVV. AVS/CVV checks should work for recurring billing initial payment since its processed through AIM calls and profile is created afterwards. Its different when you choose to save the card where we seem to be saving the profile first and then paying with it.

In code we are explicitly asking for the AVS/CVV validation when saving a card but it doesn't seem to work as expected. It needs at least one line update to trigger the validation and few more lines of code to pass the AVS since its a pre-order stage.

I am going to update the existing report, thanks for the valuable feedback. Let me know if you want to try the change needed to ensure CVV/AVS validations are done when creating a profile. This is different from ExtraOptions fix that you suggested which maybe still valid when you are paying through an already existing profile.

Joe Payne @ AbleMods LLC  
#15 Posted : Friday, May 22, 2020 6:03:37 AM(UTC)
Joe Payne @ AbleMods LLC

Rank: Advanced Member

Groups: Developers
Joined: 11/9/2018(UTC)
Posts: 92

Thanks: 11 times
Was thanked: 5 time(s) in 5 post(s)
I agree that subscription recurring charges won't have the same opportunity to pass CVV as it cannot be stored. So making CVV required in AuthNet will probably cause future recurring charge payments to fail.

As it's written now, checking the save card profile triggers CIM instead of AIM. But even if you fire AIM first to trigger an AVS check, that's only going to validate on the first use. There's no guarantee the bill-to will be correct on subsequent orders using CIM if you don't pass it on every CIM call.

If you could get the initial save-profile to validate CVV, then add bill-to via extraOptions, you've covered all the bases in opinion. Subscriptions still work because CVV isn't mandatory in AuthNet. And admins get usable AVS responses for regular orders using stored profiles.

Only checking the AVS/CVV one time during the create-profile creates an inconsistent order processing scenario. The store admin is already disciplined to check the AVS and CVV responses on every payment. Now we'd be asking them to respect the response on AIM orders, but ignore the response on CIM orders because stored-profile was validated when it was originally created.
mazhar  
#16 Posted : Friday, May 22, 2020 10:26:53 AM(UTC)
mazhar

Rank: Administration

Groups: Admin, Administrators, HelpDesk, System, Authorized User, Developers, Registered
Joined: 10/5/2018(UTC)
Posts: 64

Thanks: 5 times
Was thanked: 8 time(s) in 7 post(s)
Quote:
If you could get the initial save-profile to validate CVV, then add bill-to via extraOptions, you've covered all the bases in opinion. Subscriptions still work because CVV isn't mandatory in AuthNet. And admins get usable AVS responses for regular orders using stored profiles.

Yes, this is what we will be looking into. A fix to ensure validation works when adding/updating profiles, make sure that AVS/CVV checks are performed for payments made through profiles.
katie_able_support  
#17 Posted : Monday, June 15, 2020 7:40:37 PM(UTC)
katie_able_support

Rank: Advanced Member

Groups: Administrators, Developers, Registered, HelpDesk, System
Joined: 10/29/2018(UTC)
Posts: 94

Thanks: 2 times
Was thanked: 6 time(s) in 5 post(s)
Hi,

I wanted to give you a quick update. It will take me a few days to review everything here in this post, do some testing, and see if we missed this during final QA.

Thank you for your patience.

Katie
Thanks for your support!
Katie
Users browsing this topic
Forum Jump  
You cannot post new topics in this forum.
You cannot reply to topics in this forum.
You cannot delete your posts in this forum.
You cannot edit your posts in this forum.
You cannot create polls in this forum.
You cannot vote in polls in this forum.