We’re using Authorize.net. When the config is set to ‘Authorize & Capture’ it works fine. When we set it to Authorize only - all cards are declined.
Any ideas?
Hmm, what version of the cart? On 2.0.15 I have no problems (other than British zip codes) and all my sales are AUTH_ONLY.
Okay, we looked at the code and saw the http post function is writing to the log so we looked at the log entry. Here’s the issue, CS-Cart is masking the confidential information such as the credit card and cvv number with X’s. So it is sending to Authorize.net a card number of XXXXXXXXXXXX0924 and CVV XXX.
We verified this by editing the authorizenet_aim.php and right after these lines:
/ CC information
$pp_data[] = “x_card_num=” . $order_info[‘payment_info’][‘card_number’];
$pp_data[] = “x_exp_date=” . $order_info[‘payment_info’][‘expiry_month’] . ‘/’ . $order_info[‘payment_info’][‘expiry_year’];
$pp_data[] = “x_card_code=” . $order_info[‘payment_info’][‘cvv2’];
We added these lines:
echo “card code = “.$order_info[‘payment_info’][‘cvv2’].”
card_num = “.$order_info[‘payment_info’][‘card_number’].”
”;
exit;
which are right before:
$__response = fn_https_request(‘POST’, $payment_url, $pp_data);
The output was:
card code = XXX
card_num = XXXXXXXXXXXX0924
So the X’s are being masked on the values in the payment_info array before it actually sends the request. We thought maybe it was just doing that to keep the info in the log secure.
No to figure out why it is doing it.
This appears to be the problem, my initial guess at least.
Looking through fn.cart.php I see the way 2.0.15 works is it first writes the order to the DB, THEN it processes the payment. So what is happening is it is storing the credit card info in the order record masked with X’s, which is fine (interesting that on top of that it is encrypting it).
What CS-Cart seems to be saying is, you are using a payment processor so you don’t need to see the credit card number. But even if I delete all the orders logout, log back in and submit a new order, the first time I submit the card, it still tries to submit the number to the processor masked with XXX’s.
It will only mask the XXX’s in the DB if the setting for “Remove CC info” is checked.
I know they modified how the logs are being output since putting CC info there is a PCI issue. But I’d be very surprised if they injected a major bug like sending XXX’s to Anet and you’re the first to experience it.
If the behaviour you note is true, then this should be submitted as a critical bug to the bug_tracker and the newest release should be held up pending it’s resolution.
Hello, we have this same issue. Was it ever resolved?