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

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.

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

Sure

The customers ability to securely store a credit card with the merchant is quite popular and definitely increases sales.

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.

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,

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

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.

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