Hi Marco,

In regards to the AVS issue, the only thing Ablecommerce has to do is pass the billing information to the gateway. That billing information includes the first numerical part of the billing address and the billing ZIP Code. That's the only two pieces of information the gateway uses to check AVS.

What AVS responses are you getting from authorize.net?

B, E, R, G, U, S, N, A, Z,W, or Y ???

I believe these are the only responses issued by authorize.net. Ablecommerce does not participate in the decision to deny a credit card payment once the information has been sent to your gateway,you better check with authorize.net to see what security settings you have in place. Also look at the AVS response and make a determination from there.

Even return customers can use different billing addresses and different credit cards. The only restriction we have on our end is deny the purchase if the security code is incorrect, again setting at the gateway level, not the shopping cart.

I'm sorry to hear about the other issues that you're having, I have found that if you properly document and Ablecommerce can verify the issue, they will even give you code fixes before the next release. At least that has been my experience working with them for a short time.

I am pretty sure you are aware that if you move to Shopify, once you have 800k in sales, you're going to be locked into the $2,000 plus shopping cart fee? - You are aware of this, correct?

Best of luck in fixing your issue,
-Ray

Edited by user Monday, July 27, 2020 7:13:55 AM(UTC)  | Reason: Not specified

B(decline) E(decline) R(Allow & Report) G(Authroize & Hold) U(Authorize & Hold) S(Allow & Report)

N(decline) A(Allow & report) Z(Allow & Report) W(Allow & Report) Y(Allow)


Made changed today
N(decline) A(Allow & report) Z(Authroize & Hold) W(Authroize & Hold) Y(Allow)



All these settings are considered very loose on the security checks. The problem was that a lot of customers used the same card and the same billing address got declined because of AVS mismatched. How could it be? We double-checked it all info matched.

I really suggest that you follow Naveed advice and send him what he is requesting, the Authorize.NET CIM.Log file.

If Ablecommerce is properly passing the information to your gateway, you have a gateway problem.

-Ray

As of today, we still have issue of payment bing declined. Strange enough that some of those payments if process in our system manually, it passed the check and transaction was successful.

Many customer complained the issue because they were using the same info before; same billing address on the same card. I don't understand why it worked in the past (before upgrade to v9) but not today while security check level on Authorize.net was reducted. Everytime the system complained that billing addresss didn't match. But how come it worked out when we tried the transaction from our end at work?? It means to me that some info got 'lost' during the form submitting. Could it be encryption issue? FYI, most customers insisted that the billding address was correct, and verified that fund was withdraw from their bank.

I did. I sent log file about 10 days ago

My recommendation to you is to follow the advice of tech support and send the information that they are requesting. I suggest that you log into your authorize.net account, go under reports, and start printing out all the transactions that have been declined.

Send this information to support, if you feel uncomfortable sending this information using this form, I am pretty sure they can provide a private email.

Without detailed information, there is very little anyone can do to help.

I hope you fix your problem.

The reports that I mentioned are reports, not log files. They come directly from the backend, the administrator portion of authorize.net. These reports should show you why the transactions were declined. This is coming from authorize.net, not Ablecommerce.

Ablecommerce should not be the one denying the credit card transaction, unless there's some security feature in Ablecommerce that's checked, the credit card transaction is being denied by the credit card holder's banking institution and this information should be picked up by authorize.net, which is nothing more than the gateway. If Ablecommerce somehow is not passing a necessary piece of information, this report should identify that.

Please note that you can denied certain credit card transactions based on certain filters in authorize.net, but this will show up in the daily denied reports that you have access to in the backend of authorize.net.

- Have you discussed this issue with your developer?
- Has your developer seen these reports?

If a vital piece of information is being withheld or the transaction or part of the transaction itself somehow is not being transmitted properly through secure protocols, this report should show that.

I can assure you that if we had this problem, it would have been rectified within minutes, so I am very confused as to why this problem still persists for you.

I wish you the best of luck.

This is one of case where AVS was not valided and being declined. Look at the address, all blank!! Why was that happened? The System sure will declined an other without billing address.


Payment Information
Card Type: Visa
Card Number: XXXXX708
Expiration Date: XXXX
Total Amount: USD 198.36
Order Information
Invoice #: 253400
Description: Lightobject Order #253400
Customer Billing Information
Name: Timothy xxxx
Company:
Address:
City:
State/Province:
Zip Code:
Country:
Phone:
Fax:
Email: troth12345@gmail.com

Customer ID: 3673700
Customer Type: Individual
Customer TaxID/SSN:

DL Number:
DL State:
DL DOB:
Shipping Information
Name:
Company:
Address:
City:
State/Province:
Zip Code:
Country:

Maybe this is related to an issue reported in AC Gold- BillToAddress not being passed when a stored card is used?
http://forums.ablecommer...pic.php?f=65&t=19296

After I disabled 'Enable Payment Data Storage' in the System Setting, it seems work. So far, not declined payment. But doing so would cause inconvenience for credit card refund. All refund need to call the customer for card info before able to issue a refund. Can this be fixed on next batch?