Hello Guys,
I use auth.net as the payment gateway. I told one of my friends who is a Non US resident (India ) to place an order of $5 on my site. He used his VISA card and after he clicked on the place order button his card was charged immediately however the screen was stuck on " Please wait processing order…" That message did not change he left the screen open for 20minutes and it was still the same and closed it…
In my orders area i saw his card info with a message “Declined” The transaction has been declined because of an AVS mismatch. The address provided does not match billing address of cardholder.
CVV2 was matched…
He told me that the address was 100% absolutely correct.
Is this happening because auth.net can only verify the address of US/?Canada residents?
What should i do in such cases when i get international orders? And is there any solution for that message which is stuck. ?
Thank you.
[quote name=‘rock007’]Hello Guys,
I use auth.net as the payment gateway. I told one of my friends who is a Non US resident (India ) to place an order of $5 on my site. He used his VISA card and after he clicked on the place order button his card was charged immediately however the screen was stuck on " Please wait processing order…" That message did not change he left the screen open for 20minutes and it was still the same and closed it…
In my orders area i saw his card info with a message “Declined” The transaction has been declined because of an AVS mismatch. The address provided does not match billing address of cardholder.
CVV2 was matched…
He told me that the address was 100% absolutely correct.
Is this happening because auth.net can only verify the address of US/?Canada residents?
What should i do in such cases when i get international orders? And is there any solution for that message which is stuck. ?
Thank you.[/quote]
First off, you should check with your payment gateway provider (ie authorize.net) as to what your account is specifically setup to do, theres alot of settings in regards to security checks and out of the united states charges.
I do believe, years ago, when I used authorized.net for a client of mine, and we had payments coming from canada, we had to disable the address and zip code checks, as they would never authorize even with the correct information, however, I’m pretty sure things have improved since then (like 2004).
I haven’t recently done any international payment processing, so I’m not sure, but it is always best to speak with the tech support people @ authorize.net (or any gateway provider) and find out how to properly handle the charges.
Anet has issues when the issuing foreign bank says they do AVS authorization. There seems to be a mismatch between how Anet sends the info or how the response is formatted to them.
In any event, I get failures all the time for customers from India and Britain related to AVS mismatch. And it’s usually the address field.
The customer’s card was probably NOT charged. What I’ve observed is that requests for an AUTH to certain banks will text the customer that their card has been charged when it really hasn’t. Also, some customers have no idea about the difference between a request, authorization and a capture. So that usually requires an explanation.
[quote name=‘tbirnseth’]Anet has issues when the issuing foreign bank says they do AVS authorization. There seems to be a mismatch between how Anet sends the info or how the response is formatted to them.
In any event, I get failures all the time for customers from India and Britain related to AVS mismatch. And it’s usually the address field.
The customer’s card was probably NOT charged. What I’ve observed is that requests for an AUTH to certain banks will text the customer that their card has been charged when it really hasn’t. Also, some customers have no idea about the difference between a request, authorization and a capture. So that usually requires an explanation.[/QUOTE]
Can you please give any solution for this ? I really want to do something about this. And any idea why the screen did not show up any message after the user clicked on place order and waited for the transaction to complete? It was just stuck on “please wait processing order…” how do i fix this as well?
Sounds like it was waiting for a response from Anet (or there was a PHP error on the ajax request). Do you have logging turned on for http requests? If so, go look in Administration/logs for the transaction that had a problem.
I use authnet and never have issues with international orders. We get a lot from Australia, Britain, and Canada. If you read their knowlegebase, they give you a specific setting on processing international orders. Make sure in your settings you ate least have the letter G UNchecked. You also have to have specific settings if you accept debit cards.
[quote name=‘tbirnseth’]Sounds like it was waiting for a response from Anet (or there was a PHP error on the ajax request). Do you have logging turned on for http requests? If so, go look in Administration/logs for the transaction that had a problem.[/QUOTE]
hmm not sure where to see if i have the loggin turned for http requests?
By the way all of these are checked:
Enable secure connection at checkout (SSL certificate is required to be installed on your server)
Enable secure connection in the administration panel (SSL certificate is required to be installed on your server)
Enable secure connection for authentication, profile and orders pages (SSL certificate is required to be installed on your server)
Keep HTTPS connection once a secure page is visited
And i noticed that this option is currently unchecked
Allow customers to pay order again if transaction was declined
Do you recommending checking it?
Also i found the reason why the transaction was declined…For international orders my AVS settings in the Anet account should have G, U and S options unchecked.
I had all of them checked that is what caused the Address mismatch.
I am now only worried about that “Processing order”
page which was stuck and didn’t change…It was taking forever to process so my friend had to close the window…He did that after 20minutes.
Is there any solution to this?
Again, that processing window indicates that the cart is waiting on a response from something (probably Anet) or there is either a PHP error or Ajax (Javascript) error. If your logs are clean then that would leave the waiting for Anet and now that you’ve changed your settings you may not have a problem.
IMPORTANT! PLEASE READ THIS!
We use authorize.net to process our credit card transaction.
On July 19, 2011 a person attempted to validate credit card numbers using our cs-cart store. They used a script to make 49 attempts in LESS than 10 minutes. Luckily I was sitting at the computer when I began seeing orderings flowing in, all DECLINED, from the same order! Naturally I went into immediate action. I attempted to block the customer's email address from the administration → Store Access → email tab. That failed to stop the culprit. Then, quickly I added the culprit's IP address (mistakingly) to the Administration → Store Access → Domain tab. I should have entered into the IP tab. Of course that did not work. I then immediately called WiredTree tech support and they immediately implemented an IP address block which instantly successfully blocked the attacker. Now, here's where the BIG problem is…
That person, in less than 10 minutes, attempted 49 TIMES to obtain a valid card number, fortunately all attempts were DECLINED. But guess what? Authorize.Net is charging us $0.05 per attempt!!! $2.45 total. “No big deal” you may think. However, what if I was not at the computer to stop the attacker? That attack would have continued for hours and hours and even days! I brought this matter to the attention of Authorize.net personnel and they absolutely refuse to remove the charges, using the canned response that "unfortunately, at the present time there is no method for them to remove the $0.05 charges. They suggested we subscribe to the Advanced Fraud Detection service - which does NOTHING to stop or prevent repeated attempts to validate card numbers. The service would only DECLINE the transaction. If 200,000 attempts were made, resulting in $10,000 of fees, at $0.05 per transaction, WE WOULD BE CHARGED!!! That is outrageous! This is applicable to EVERYONE who uses authorize.net as their gateway.
I submitted a statement to cs-cart help-desk telling them what happened to us. This is, in part what I stated: “…isn't there some way we administrators can set a LIMIT how many times an order is submitted after being declined? We believe this should be STANDARD FEATURE in ALL shopping carts. I am really surprised cs-cart does not contain this VITAL function.”
This was their reply: “Unfortunately, there is no way to configure the default CS-Cart store to work in this way. Requests of this kind are not covered by our technical support service. Yet, I suggest that you should consider our custom development service. Our custom development specialist can explore whether it is possible to change CS-Cart code to meet your requirements and, if possible, can estimate your request.”
Yes, we are aware that in the ADMINISTRATION → SETTINGS we can “Allow customers to pay order again if transaction was declined”, or un-check that box. But, restricting the customer to 1 attempt is not logical or advisable because we have many customers that make a mistake entering either the card number or the expiration year or CVV.
This event has made us aware of authorize.net obscene lack of protection against fraudulent attempts to validate cards. The authorize.net customer WILL be charged for each and every attempt. So, in light of the above issue, we have turned off the credit card payment method in cs-cart (at least temporarily) and are instead using PayPal for all cs-cart order submissions. Note: PayPal now accepts credit card payments without the customer having a PayPal account.
As I stated to cs-cart help-desk, cs-cart should, by default, have a method whereby we can LIMIT how many times an order is re-submitted after being declined. We believe 3 times would be an acceptable number of times.
In light of the above, does anyone have any input to offer?
Thanks ~ Bill Galkowski, manager/developer
July 24, 2011 Update: After considerable thought I'm not sure if a cs-cart feature to LIMIT how many times a declined order is re-submitted would be affective against someone running a script. This is definitely a CS-Cart vulnerability. After all, that's apparantely how we were attacked, via a script. I mentioned that to CS-Cart tech support and am waiting for their response.
Bill G,
Sorry to hear about the headache.
3 times seems reasonable.
Please post a suggestion in the idea area with a link in this thread
I don't think Anet is at fault nor should they be expected to throttle the transactions. What if you had a high volume site?
It would be a pretty simple mod keep count of the attempts in the user's SESSION and when it exceeded a threshold, to prevent them from doing any more transactions. You'd probably do this on the 'place_order' mode of the checkout controller.
You might try adding the following to a file named addons/my_changes/controllers/customer/checkout.post.php
```php
define( 'my_max_order_attempts', 3);
if( $mode == 'place_order' ) {
if( !isset($_SESSION['auth']['order_attempts']) ) { // first time
$_SESSION['auth']['order_attempts'] = 0;
}
$_SESSION['auth']['order_attempts']++;
if( $_SESSION['auth']['order_attempts'] > my_max_order_attempts ) {
// Recommend adding code to remove the user from the customer database....
die('Access denied'); // Don't give them any idea why
}
}
return array(CONTROLLER_STATUS_OK);
?>
```
That should do what you're looking for… Note that a logout/login will reset the counter or if they are anonymous, logging in will reset the counter.
[quote name='tbirnseth' timestamp='1311453351' post='118083']
I don't think Anet is at fault nor should they be expected to throttle the transactions. What if you had a high volume site?
It would be a pretty simple mod keep count of the attempts in the user's SESSION and when it exceeded a threshold, to prevent them from doing any more transactions. You'd probably do this on the 'place_order' mode of the checkout controller.
You might try adding the following to a file named addons/my_changes/controllers/customer/checkout.post.php
```php
define( 'my_max_order_attempts', 3);
if( $mode == 'place_order' ) {
if( !isset($_SESSION['auth']['order_attempts']) ) { // first time
$_SESSION['auth']['order_attempts'] = 0;
}
$_SESSION['auth']['order_attempts']++;
if( $_SESSION['auth']['order_attempts'] > my_max_order_attempts ) {
// Recommend adding code to remove the user from the customer database....
die('Access denied'); // Don't give them any idea why
}
}
return array(CONTROLLER_STATUS_OK);
?>
```
That should do what you're looking for… Note that a logout/login will reset the counter or if they are anonymous, logging in will reset the counter.
[/quote]
Thanks for the input and suggestion tbirnseth.
I tried the code mod suggestion but unfortunately it didn't work. It created the file and placed it as you suggested, I even tried adding your suggested code to store/controllers/customer/checkout.php file in the “if ($mode == 'place_order') {…” section. Any suggestions? Otherwise, I guess I will just wait for cs-cart custom development to give me a price quote.
Thanks again for the suggestion.
Bill G.
“It didn't work” isn't too helpful in trying to find why it's not behaving as I would have expected.
The code I provided was simply the 10 minute brain-dump that one would expect in free advise. If you can provide further detail/diagnostics about what doesn't work, then I might be able to advise. If you'd like me to debug/diagnose/develop the solution for you, go to my site and request a quote and I'll be happy to get it sorted out for you. It is not a difficult problem.
Bill I can vouch for tbirnseth's work. He's well versed in CS-Cart and I'm running several of his addons
[quote name='tbirnseth' timestamp='1311563256' post='118148']I do see where it could be a problem if someone is using an automated tool to shove CC numbers through your checkout process waiting to find one that “hits”.[/quote]
Greetings tbirnseth.
I believe that is exactly what the person was attempting to do because they submitted 49 times, different card numbers and CVV info in less than 10 minutes. When looking at the authorize.net log it had been done so fast some of the submissions, instead of showing “DECLINED” showed as “general error”.
[quote name='tbirnseth' timestamp='1311562172' post='118146']
“It didn't work” isn't too helpful in trying to find why it's not behaving as I would have expected.
The code I provided was simply the 10 minute brain-dump that one would expect in free advise. If you can provide further detail/diagnostics about what doesn't work, then I might be able to advise. If you'd like me to debug/diagnose/develop the solution for you, go to my site and request a quote and I'll be happy to get it sorted out for you. It is not a difficult problem.
[/quote]
I apologize for not initially providing more details as to why it did not work. Here is more details: Following your instructions exactly, I created the file you instructed and placed the code you provided in said file, setting a maximum number of order-declined submission attempts to 3. I then created the directory you suggested and uploaded the said file to the said folder you directed it be uploaded to. I then created an order (like I was a customer) selecting a product, added it to the cart, then continued through the checkout process using a test VISA CC number. I then submitted the order, approximately 6 times. Then, I logged into authorize.net and there were 6 declined processes - indicating that the max attempts code you provided apparently wasn't recognized.
Then, trying an alternate method, I placed the code you provided in the store/controllers/customer/checkout.php file in the [color=“#FF0000”]“if ($mode == 'place_order') {…”[/color] section. Then, I went to the customer side of the cart, and created a new order and submitted it like I did the previous order that I described above. That didn't work either. When I submitted the order a message appeared…“Oops, Something is wrong!”
I hope my above description is adequate tbirnseth. As I indicated previously, I brought this CS-Cart vulnerability issue to CS-Cart tech support's attention I believe on Saturday. I am waiting for their response. After I receive their response, if it is not acceptable by me, I will contact you as you suggested, i.e., to debug/diagnose/develop.
Thanks for your time tbirnseth.
UPDATE July 25, 2011 10:02 EST: I just received the following reply from CS-Cart tech support:
[quote name='racingsolution' timestamp='1311571039' post='118155']
Bill I can vouch for tbirnseth's work. He's well versed in CS-Cart and I'm running several of his addons
[/quote]
Thanks for your input racingsolution. As I replied to tbirnseth, if I am not satisfied with CS-Cart tech support's response I will be contacing tbirnseth through his website for a quote. However, I do believe this is a CS-Cart vulnerability and I further believe that CS-Cart development should provide a fix - FREE of charge, because, (in my opinion) everyone that uses CS-Cart shopping cart along with authorize.net is exposed to this same unrestricted declined-order re-submission vulnerability.
Thanks again racingsolution.
If there were no actual errors, then some debugging/testing would be required.
As I said, this is not complex code, but it could be that we need to stick the code under a different 'mode' but I would think that 'place_order' would be correct.
One additional thing to try… copy/paste this code into addons/my_changes/controllers/customer/orders.post.php
It's the same as before, just a different condition for the mode since it's using orders.repay rather than checkout.place_order for the subsequent requests. I'd leave both in place. The first will initialize it, the 2nd will catch it.
```php
define( 'my_max_order_attempts', 3);
if( $mode == 'place_order' ) {
if( !isset($_SESSION['auth']['order_attempts']) ) { // first time
$_SESSION['auth']['order_attempts'] = 0;
}
$_SESSION['auth']['order_attempts']++;
if( $_SESSION['auth']['order_attempts'] > my_max_order_attempts ) {
// Recommend adding code to remove the user from the customer database....
die('Access denied'); // Don't give them any idea why
}
}
return array(CONTROLLER_STATUS_OK);
?>
```
[quote name='tbirnseth' timestamp='1311617886' post='118225']
If there were no actual errors, then some debugging/testing would be required.
As I said, this is not complex code, but it could be that we need to stick the code under a different 'mode' but I would think that 'place_order' would be correct.
One additional thing to try… copy/paste this code into addons/my_changes/controllers/customer/orders.post.php
It's the same as before, just a different condition for the mode since it's using orders.repay rather than checkout.place_order for the subsequent requests. I'd leave both in place. The first will initialize it, the 2nd will catch it.
```php
define( 'my_max_order_attempts', 3);
if( $mode == 'place_order' ) {
if( !isset($_SESSION['auth']['order_attempts']) ) { // first time
$_SESSION['auth']['order_attempts'] = 0;
}
$_SESSION['auth']['order_attempts']++;
if( $_SESSION['auth']['order_attempts'] > my_max_order_attempts ) {
// Recommend adding code to remove the user from the customer database....
die('Access denied'); // Don't give them any idea why
}
}
return array(CONTROLLER_STATUS_OK);
?>
```
[/quote]
I know you have a paid store but guys like you and a few others on here should have donate buttons for some of the free solutions and help you provide.
[quote name='tbirnseth' timestamp='1311617886' post='118225']
If there were no actual errors, then some debugging/testing would be required.
As I said, this is not complex code, but it could be that we need to stick the code under a different 'mode' but I would think that 'place_order' would be correct.
One additional thing to try… copy/paste this code into addons/my_changes/controllers/customer/orders.post.php
It's the same as before, just a different condition for the mode since it's using orders.repay rather than checkout.place_order for the subsequent requests. I'd leave both in place. The first will initialize it, the 2nd will catch it.
```php
define( 'my_max_order_attempts', 3);
if( $mode == 'place_order' ) {
if( !isset($_SESSION['auth']['order_attempts']) ) { // first time
$_SESSION['auth']['order_attempts'] = 0;
}
$_SESSION['auth']['order_attempts']++;
if( $_SESSION['auth']['order_attempts'] > my_max_order_attempts ) {
// Recommend adding code to remove the user from the customer database....
die('Access denied'); // Don't give them any idea why
}
}
return array(CONTROLLER_STATUS_OK);
?>
```
[/quote]
Hello tbirnseth.
I'm confused. Maybe I'm missing something here, but, the new code you provided is [exactly] the same as the original above. Also, you state “I'd leave both in place.” My response is: leave both of [what] in place.
UPDATE: Disregard my above statement. I see what you were referring to “[color=”#8B0000"]orders.post.php[/color]" and “[color=”#8B0000"]checkout.post.php[/color]".
Okay, I just tried it using the new file names. Results: had no observable affect whatsoever on preventing declined order submissions beyond the set maximum limit. I also logged into authorize.net and each declined transaction was listed. Keep in mind that I am using a visa test cc number, so it should be declined, but, as I indicated, each submission beyond the max limit was transmitted to authorize.net.
Oh well, would require debugging and can’t do that from here.
John - you can always go to my site and click Catalog/Services and then click Consulting and enter any price you would like to contribute. I don’t think I’ve ever refused to accept money! 