[whdcoinc]

So, about a month or so ago, I had a fraudulent charge due to shipping address different than billing address, and cc owner claimed fraudulent charge. Fine. So I decided to limit my shipping to billing address only.

Yesterday, I got a fraudulent charge because the billing address that was entered (and shipped to) was the wrong address for the credit card. My payment processor said that my shopping cart is accepting any order and processing it, even if the entered billing information doesn't match the actual credit card information.

I've checked a few more recent orders and found that CS Cart is accepting credit cards even when the address AND the CVV2 numbers don't match the actual credit card.

My payment processor told me that since it was coming from my shopping cart, I would have to verify each and every purchase myself, manually.

This is ridiculous! How am I supposed to verify each and every order manually myself?

Doesn't CS Cart have some way to determine or reject a credit card if the information entered doesn't match the card?

Anybody have any insight on this?

[clips]

Sorry, but this is not the fault of CS-Cart. You need to get with your payment gateway and set the fraud settings. CS-Cart does nothing but pass along information, it does NOT do fraud stuff. For example, we use Authorize.net as our payment gateway. They are not our bank, they are our gateway from the website to the bank. I am guessing that you should have a way to log in to your gateway. Once you log in to your "gateway" you will need to find out where to set up your fraud level. For example, I have it set that it will not allow a card to go through if the address, zip and cvv2 do not match.

[whdcoinc]

Thanks for your reply.

I've already spoken to my payment processor. They told me that the payment information coming from CS Cart also contains an auth/sale code or something that bypasses their system. Basically they said that CS Cart is sending a code that tells them to process it immediately.

Of course, there is every possibility that the tech I spoke with had no clue what she was talking about. I'm still trying to figure it out.

I'm using an Authorize.net emulator with my payment processor. From what I was told, and from what I can tell, it bypasses their check system because it sends some code saying approve it.

[clips]

You need to log in to your Authorize.net, which is who is the gateway and where the fraud settings are controlled. Again, CS-Cart does nothing but send in the information, it does NOT do the fraud protection side. Your payment gateway, which is Authorize.net for you, is who controls it.

[brandonvd]

Yep, Jim is right. All CS-Cart does is pass along the numbers.

I use Authorize.net and have been very happy with them.

When you login to Authorize.net, go to your settings. Then you can change your security settings. I'm not a security expert, but here is how I have my address settings:



Authorize.net also has a Fraud Detection Suite that might help you.

I hope that helps,

Brandon

[racingsolution]

When Authorize.net emails me transaction info, I ALWAYS verify the address in the email with what the customer inputted.. I've never had it be different, but it gives me some peace of mind.

[clips]

We don't require the extended zip to be accurate, but we do require the address and zip. So we have the "Y" chosen in the admin for Authorize.net

[The Tool]

The key word yall are missing in whdcoinc's post is "emulator" which means to me that Authorize.net is not actually being used.

[whdcoinc]

Tool, that is correct. My payment processor is eProcessingNetwork. They are firearms friendly, and very reasonably priced. However, as you and I stated, to connect I am using an Authorize.Net emulator.

Ugh. I believe it is not the problem with CS Cart, but I just need to get the right answer from ePN.

Thanks all.

[clips]

If they have an "emulator" then you would think they would have a way to administer it still.

[whdcoinc]

Here is the answer I got from my payment processor:

Under the processing controls we have preprocessing information that you can select to provide a tighter setup. The only thing that would hinder you from using that is the setup you have within your cart. If you remove the X_Trantype selection from the variables within the cart you can use our preprocessing controls and select the type of transactions that you can convert to sales. If you are unable to remove that variable from the code you will not be able to use the preprocessing controls.

So, from what it sounds like from my payment processor, for some reason cs cart is sending a transaction type that is telling my payment processor to process the payment regardless of the payment preprocessing controls.

So, I guess I need help figuring out exactly what is going on and how to fix it to make it work properly.

For example, how do I find out what transaction type cs cart is selecting to send to my payment processor?

[The Tool]

What you need is a legit payment processor.