First 4 digits of card number help

[beadmerrily]

Hello all,

 

I've had an OSC shop for a couple of years www.beadmerrily.co.uk and i've finally got a credit card machine and an SSL certificate beingp ut on today.

 

I'm now fiddling with the credit card module, which is the only one i have installed (i think it was a default?) but first tresting is showing it recognising the first 4 digits of a mastercard but not of my maestro card.

 

I've assuming there must be a default list of numbers to add in for it to accept somewhere but i'm not having luck finding it - and i'm also not sure where to stick them when i find them!

 

Could anyone help me? I'm trying to empower myself and not rely on help from the more technologically enabled than myself these days, but it is an uphill struggle when you didn't install it in the first place!

 

Many thanks in advance :blush:

 

Merry

xxx

[dynamoeffects]

That's because the default /includes/classes/cc_validation.php script doesn't handle UK cards. Search the contributions for the UK cc validation script, or download my PayPal contribution and copy my rewritten version from there.

[beadmerrily]

That's because the default /includes/classes/cc_validation.php script doesn't handle UK cards. Search the contributions for the UK cc validation script, or download my PayPal contribution and copy my rewritten version from there.

 

Oh thank you! I think most of my problem might have been that i wasn't quite sure what i was actually searching for so i wasn't getting very far!

 

Will go and look for your contrib - will it tell me where to erm... stick it? ;)

[dynamoeffects]

Actually, try the other one. I just looked and only added Switch/Solo support.

[sweet-au]

You want to check to see if everything is PCI compliant. Here in Australia a good friend of mind got hit with a $5,000 fine and lost his merchant account because he was using the cart itself to take cc payments, store half of it on a shared webserver and send half of the numbers by insecure email.

 

I know there's a lot of misunderstanding about these new PCI rules but geez they don't mess around now.

 

I have a manual merchant account which is pretty cheap and I charge the cards myself. I didn't want to go the real time gateway route - heaps too expensive. My bank put me onto the E-Path Manual Credit Card Gateway if I wanted to stay doing things manually.

 

In Australia what's happening with the PCI thing and the trouble you can now get into is putting shivers up everyone's spines. Its just way too risky now and I don't know enough about it to be happy taking any risks at all. Better to be safe than sorry I guess, but its not that expensive to do things right so maybe its all for a good reason, who knows.

 

Other than e-Path the only other proper manaul one I know of is Payecom Manual Payment Gateway. Hope this helps you.

 

Bye for now.

[squalid]

just to agree with the above

 

- very important to check your bank will allow this and i doubt they will

[dynamoeffects]

I don't think you two understand the problem. We're discussing the cc_validation.php class which simply validates the credit card number before submitting it to the processor. This has nothing to do with storing numbers or PCI regulations.

[beadmerrily]

I don't think you two understand the problem. We're discussing the cc_validation.php class which simply validates the credit card number before submitting it to the processor. This has nothing to do with storing numbers or PCI regulations.

 

Gulp. No, i think it is okay. My merchant account know what it is for, i have a SSL cert and my hosts are the most super security conscious people i know. I barely sniff and they know i've done it :)

 

Astonishingly (because obviously i didn't actually think of this straight away and simple is so rarely the obvious answer) my merchants have given me a list of numbers so now i just need to find that cc_validation file.. which i can't - but i'll get there!

 

Merry

xxx

[beadmerrily]

Ah ha! it was in classes... of COURSE!!!! :rolleyes:

 

Thanks again all... appreciate it :)

 

Merry

xxx

[squalid]

I don't think you two understand the problem. We're discussing the cc_validation.php class which simply validates the credit card number before submitting it to the processor. This has nothing to do with storing numbers or PCI regulations.

 

you are right, i dont understand :blush:

 

if using a payment processor - like protx in the UK - then the cc number would be validated by protx - or whatever payment processor used and so no need to put the cc number in the site - instead on protx form.

 

it is very hard to get banks to agree to allow customers to input card details on the website and there is all sorts of crtiera to go through, and its not a case of just having a merchant account and an ssl.

 

question - would taking the credit card details - then passing them through the cc_validation.php automatically store them in the database ?

[dynamoeffects]

No. cc_validation.php simply performs a LUHN-10 check on the card number to ensure that it's in the correct format. Most payment processors charge you per-transaction, whether it's declined or not, so you want to ensure that the credit card number you send is actually a credit card number and not someone's telephone number.

 

The payment module is what would save the number to the database, and each one is different. With my PayPal Pro module, it stores the number like this: 4111XXXXXXXX1111. The purpose is so that you can confirm the number with your customer while not jeopardizing their personal information or opening yourself up to fines from Visa/MC.

[sweet-au]

No. cc_validation.php simply performs a LUHN-10 check on the card number to ensure that it's in the correct format. Most payment processors charge you per-transaction, whether it's declined or not, so you want to ensure that the credit card number you send is actually a credit card number and not someone's telephone number.

 

The payment module is what would save the number to the database, and each one is different. With my PayPal Pro module, it stores the number like this: 4111XXXXXXXX1111. The purpose is so that you can confirm the number with your customer while not jeopardizing their personal information or opening yourself up to fines from Visa/MC.

 

So you can't re-bill or do recurring charges, is this correct?

Edited February 8, 2007 by sweet-au

[dynamoeffects]

No, every payment module is different. Some people have written it so that it stores the entire number into the database (including the CVV2 number, which is expressly verboten). Others, no. If you're going to have to charge your customers monthly on a regular basis, you have three choices:

 

1) Select a payment gateway/merchant account that offer subscription payments in their list of services, so that you don't have to store the numbers yourself.

 

2) Get two dedicated servers (CC#s have to be stored on a separate server), hire a systems administrator well-versed in server security, and have your site audited by a PCI compliance service every 1-3 months.

 

3) Store the numbers in your default osCommerce store with a $1k SSL certificate and pray that no one hacks into your site.

[squalid]

No. cc_validation.php simply performs a LUHN-10 check on the card number to ensure that it's in the correct format. Most payment processors charge you per-transaction, whether it's declined or not, so you want to ensure that the credit card number you send is actually a credit card number and not someone's telephone number.

 

i think this is wrong, as an invalid number wouldnt even be attempted to be authorised and no payment gateways that I know of in the UK would charge for an invalid card number - if they did then surely i would be onto all compeitors sites who use that gateway - inputting incorrect numbers so they incurr the charges

 

i also think that having a payment gateway and all associated with it - you would then be defeating the point by having customers place the card number on your site - i personally would find it very confusing to place the card number on one site then suddenly see the card details on a payment gateway form

 

3) Store the numbers in your default osCommerce store with a $1k SSL certificate and pray that no one hacks into your site.

 

this is v.bad and would certainly break the terms of your merchant account. when i looked into taking cards via a website - HSBC in the UK told us that to meet their requirements we had to conform to all the critera set by http://www.ubizen.com/

 

so best advice here really is speak to your bank, see what you need. Having a merchant account and SSL does not mean that you can automatically take credit card numbers on your website

[dynamoeffects]

i think this is wrong, as an invalid number wouldnt even be attempted to be authorised and no payment gateways that I know of in the UK would charge for an invalid card number - if they did then surely i would be onto all compeitors sites who use that gateway - inputting incorrect numbers so they incurr the charges

 

No, they will charge you the transaction fee even if the card is declined. That is how it works and it is nearly universal. Doing what you're suggesting would amount to fraud, and most store owners would/should report you to the police should you attempt it.

 

i also think that having a payment gateway and all associated with it - you would then be defeating the point by having customers place the card number on your site - i personally would find it very confusing to place the card number on one site then suddenly see the card details on a payment gateway form

 

With a normal payment gateway, you would never see their site. The customer enters their information at the store's website and the transaction is done behind the scenes. If your gateway service sends the customer to their site, you shouldn't be asking for credit card information on yours.

Edited February 8, 2007 by dynamoeffects

[squalid]

No, they will charge you the transaction fee even if the card is declined.

No, they will charge you the transaction fee even if the card is declined.

 

it would not be the case that the card was declined, if it wasnt a valid card number - it wouldnt attempt authorisation in the first place

[dynamoeffects]

From authorize.net's own words:

Discount Fee

The percent of each credit card or eCheck.Net® transaction and batch settlement processed that is billed to the merchant by the payment gateway. The transaction types for which the discount fee is charged are: charges, refunds, voids and declines.

 

Feel free to research other payment gateways and ask about their policies.

[squalid]

an invalid card number is not a declined card as an invalid card number hasnt even attempted authorisation

[dynamoeffects]

Wow. Just wow. Perhaps someone else would like to step in because this guy is really trying hard not to understand.

 

A connection to your payment gateway in which you attempt to charge a card based on the information given by the customer = transaction. If I enter ABCDEF12345 as my credit card number in your store, and that information is sent to your payment gateway, that is a transaction, and thus, a fee. Everytime your store connects to their server for the purpose of closing a sale, you will be charged. Period. End of story.

 

That is why we have the cc_validation.php script, so that the store can verify that the credit card number is, at the very least, in the correct format and not the customer's telephone number.

 

I've been doing this for many years. Trust me.

[squalid]

We have three pricing packages depending on your authorised transaction volume. You can use any or all of the Protx products under the same pricing package. Protx do not charge for failed or invalid transactions, nor include them in our volume calculations.

 

an invalid card wouldnt attempt authorisation. if anyone is using a payment gateway that would charge you because the customer put in an incorrect number - time to look again, as an invalid number wouldnt attempt to be authorised.

[dynamoeffects]

Ok, we're discussing two different types of services here.

 

What I'm discussing and what this thread is about: A transparent payment gateway service where the customer enters all information on your site, which is where cc_validation.php comes to play, and everything is done behind the scenes. The customer never leaves the store's website.

 

What you're discussing: A paypal-like service where the customer enters all information onto the payment service's website instead of the store's website, thus negating the need for cc_validation.

[Guest]

I think what squalid is try to explain is that there is a difference between invalid cards and declined cards.

 

cc_validation checks that the card number is valid, the payment gateway often also checks the card number is valid then attempts authorisation. It is the merchant bank that either replies with an "authorised" or "declined" response - if the card number is invalid it is never passed to the merchant bank so is therefore never declined but simply invalid (the card number defines the card issuer as well as the individuals account- if the number is invalid then the merchant bank won't be able to figure out which bank to contact).

 

Payment gateways that I know of and definately Protx with whom I use - direct method (i.e customer is not redirected to external site) do not charge for transactions with invalid card number) but perhaps there are payment gateways that do in other countries.

 

Given this situation and the fact that cc_validation is rather outdated at the current time and rejects many valid card types I have removed most of the functionality for the Protx direct module and leave the validation step to the payment gateway.

 

Tom