CC Details sent to be used off line?

[formula1]

Hi,

 

Hopefully one you knowledgeable people might be able to help or advise me on something.

 

Basically, we run an online store, (currently using Paypal Pro (UK) to process credit card transactions) and we also have a physical store where we take payments through a card machine, this is also used for mail order payments.

 

What i am wondering is what are the legalities and would it be possible for us to have the order details including the full card details emailed so we can put them through our machine and save a fortune on paypal fees.

 

Thanks in advance

 

 

Gaz

[♥toyicebear]

Hi,

 

Hopefully one you knowledgeable people might be able to help or advise me on something.

 

Basically, we run an online store, (currently using Paypal Pro (UK) to process credit card transactions) and we also have a physical store where we take payments through a card machine, this is also used for mail order payments.

 

What i am wondering is what are the legalities and would it be possible for us to have the order details including the full card details emailed so we can put them through our machine and save a fortune on paypal fees.

 

Thanks in advance

 

 

Gaz

 

 

Not by email, but there are solutions...

 

IF you are PCI compliant you can collect cc for later manual processing.

 

To read more about becomming PCI compliant ... Click me....

 

 

Or you can use an online service which stores the info for you in a PCI compliant environment

 

To read more ... Click me...

 

 

Or you can use a service like PROTX payment gateway connected to your own merchant account...

[♥Vger]

including the full card details emailed so we can put them through our machine and save a fortune on paypal fees.

 

Read the small print of the agreement you have for your EPOS terminal and you'll find that it's illegal to process internet transactions through your EPOS machine.

 

You could not become PCI compliant if it is your intention to store card details on a shared server - and you would also be in violation also of the Data Protection Act if you did so.

 

As you are UK based Protx Direct is by far your best solution. They charge around £20 per month, but up to 1000 transactions per quarter are included in that fee. The customer remains on your website, it's only the data which goes back and fore, and there's no storage of card details. Also, with the latest osCommerce Protx Direct module you can VOID and REFUND (partial or full) Protx orders via your osC admin panel.

 

Vger

[failsafe]

You could not become PCI compliant if it is your intention to store card details on a shared server - and you would also be in violation also of the Data Protection Act if you did so.

 

As you are UK based Protx Direct is by far your best solution. They charge around £20 per month, but up to 1000 transactions per quarter...

Vger

Hi Vger, you seem to know a lot about this stuff so perhaps you can help me. I'll continue this thread because my question runs along the same vein regarding PCI compliance.

 

I'm currently altering my shop to use Protx gateway, but I'm getting hung up on the PCI compliance issues and exactly which interface to Protx to use. My shop is hosted remotely on a shared server, but I do have a dedicated SSL certificate for it and the server has a fixed IP address. I've been testing using the Protx VSP Form interface, but I don't really like the way that control is lost to Protx during the payment processing part, and the 3D secure part. There also seems to be a strange issue when returning to my server after cancelling the transaction whereby the login page appears!

 

I see about 2/3 folks using osCommerce and Protx use the VSP Direct contribution instead. Do you happen to know whether this would be suitable for my situation regarding PCI compliance. I can see that module would need to collect sensitive CC data on forms hosted by my website, encrypt it and transfer it to Protx. I talked to Protx support and they seemed to think that I would need to store credit card info on my server if using VSP direct and that CC data wouldn't actually be transmitted to them. Therefore, I'm rather confused!

 

If I need PCI compliance in order to use VSP direct, then do you know what exactly I need to do to get it?

 

I also upgraded my shop to use RC2a (probably not wise but there you go) if that has any bearing on things. I haven't too many contributions installed though so it doesn't seem to have created any unresolvable issues for me.

 

Thanks in advance :)

[HappyPappy]

YES

 

You certainly can do it manually from oscommerce then into your EPOS terminal - but certainly NOT by email, that's a big no no under the PCI DSS. You will need to make sure your EPOS terminal is approved to allow card-not-present transaction entering and processing.

 

Check out e-path.com.au they are a new PCI DSS engineered manual payment gateway that allows you to do exactly as you described.

 

I've been with them for a while now and in my opinion it is an awesome service.

 

There are a couple of reasons why Visa, Mastercard and other card providers are strongly supporting these new PCI compliant manual gateways.

 

1. They don't permanently store credit card data online. EVERY real time payment gateway permanently stores credit card data in some fashion. So enabling people to pay on the net without credit card data being stored on the net negates the main reason why risk and vulnerability exists.

2. You can check things. You are not at the mercy of automated systems which I can tell you, NEVER properly protect you from charge backs.

3. No transaction fees - it is a very inexpensive system.

4. PCI compliance. Your oscommerce cart and all your hosting infrastructure doesn't need PCI compliance because you get this in the gateway package. So they give you PCI DSS compliance as far as all what you do on the net is concerned. This was a HUGE bonus for me because I wasn't aware how important this is until recently.

 

Don't get me wrong here, I'm not advertising anything, but I am wanting to point out there is a solution (probably a few of them now) that does what you need and it is 100% PCI DSS compliant.

 

Cheers

[HappyPappy]

If I need PCI compliance in order to use VSP direct, then do you know what exactly I need to do to get it?

 

Hi failsafe.

 

One single rule of thumb with PCI DSS and websites is simply ...

 

If your website touches credit card data in any way, even if it is to transmit it encrypted to your real time gateway (or Protox) you MUST have PCI DSS compliance for your site, its URL, IP, hosting, network etc etc.

 

One way to avoid needing PCI DSS compliance for your oscart is what I mentioned above, use a PCI DSS compliant manual payment gateway. With the one I use (I won't mention them again) they give me my own fully dedicated gateway system with THAWTE SSL and PCI compliant so my oscart never sees or touches credit card data.

 

Remember, if your site touches credit card data in ANY way you MUST have PCI DSS compliance for the URL, IP and everything else. Have you seen the fines if you get caught without PCI compliance. You'd need to win lotto to pay it!!!

 

Hope this helps

[failsafe]

Thanks Peter,

 

This whole subject is a minefield, I can see that. I will use the Protx Form osCommerce contribution to avoid all this PCI compliance hassle. The thing I don't like is that control is lost to their website to handle the credit card and 3D secure aspects which gives a bit of a clunky feel to checkout, plus the URL line changes to them which some customers may get alarmed about.

 

Protx also offer other interface solutions, where control stays on the shop site and encrypted information is passed to Protx from your site (see the Protx Direct osCommerce contribution). It is this scenario that I'd prefer to use because the customer experience (look and feel) can be better. However, my shop would then need to be PCI compliant it seems because CC data would need to be collected via a form on my site, even though the data isn't actually stored anywhere in my shop's database. Getting PCI compliance for a shared hosting server even with fixed IP and dedicated SSL certificate does not sound possible, given what Vger says in another related thread.

 

Incidentally, even with Protx Form (where the credit card data is collected on the secure fully PCI compliant Payment Gateway site), it's still possible to handle various different modes of processing cards. You can configure your shop to use one of 3 transaction payment types (well for Protx anyway, I assume others are similar). I'll detail them here because I'm sure there are loads of folks looking at this subject who don't understand how a Payment Gateway enables you to control how your credit card payments are processed before sending details to your merchant bank account:

 

1. PAYMENT - immediate authorisation of card and release to your merchant bank without further interaction by you. However, if you can't then satisfy the order you'd then have to log in to your Protx account and REFUND the payment (or partially refund it), thus incurring extra charges levied by your merchant bank. However, since payments are blocked and sent just once every 24 hours, you have a short time to void the payment before it gets sent to your merchant bank, thus avoiding charges for payment and refunds. You can log in to your Protx account to check how the card was authorised, CVV pass, 3D secure pass, etc. so you can avoid sending out product if you don't like the result. (More to it than this as everything is configurable as to what to do when various checks fail.)

 

2. DEFERRED - immediate authorisation and shadow placed on card, but not sent to your merchant bank until you RELEASE it by logging in to your Protx account. This gives you up to 6 days (card issuers rules) to commit the payment or VOID it, but you can't alter the amount; it's all or nothing. You need to log in to your Protx account to RELEASE the payment to your merchant bank. The benefit is that payment is authorised at the point when the customer places the order and a shadow is placed on their card, so you know you'll get the money without needing to contact the customer again.

 

3. AUTHENTICATE - checks only 3D aspects (if set up to do so) and stores credit card details for up to 90 days, but not AUTHORISED or sent to your merchant bank until you do so by logging in to your Protx account. It doesn't shadow the card and gives you longer, but you can then AUTHORISE various amounts over the 90 day period up to 115% of the value of the original transaction. You run the risk of the card authorisation failing, but obviously if so then you wouldn't send product out and would need to contact the customer to sort out payment again. (I think you're probably supposed to limit it to 30 days according to the card issuer rules, you'd have to look into it if you want to take longer.)

 

There are rules you can set up on your account that determine how/if to handle 3D secure issues, CVV failures, etc. The important thing is that using any of the above methods using the Protx Form contribution you never get so see any of the customer's credit card information whatsoever; it's all stored and handled by the payment gateway. You just log in to the payment gateway server after the fact, to see transactions that have happened and control how they are processed.

 

It's worth noting that I have (and need) an eCommerce merchant account to handle all of the above payment methods. The customer's experience is the same whichever transaction type is used anyway; the difference is in how their payment is handled behind the scenes.

 

I also have a separate MOTO merchant account that is also known to Protx so that I can take payments over the telephone or by mail order. To handle those, I have to log in to my online Protx account on their secure server and type credit card numbers supplied to me by the customer. This is similar to using a physical terminal, but means I don't actually need one. However, such MOTO payments are obviously not 3D secured so it is possible that chargebacks could occur for them.

 

Anyway, back to the subject of this thread! With the above solutions 2 and 3 you are effectively using the credit card details off-line, but you don't get to see the credit card details themselves, only the Payment Gateway sees them and stores them (Protx or whoever you use). You interact with the payment gateway via their online terminal (i.e. directly on their website using https to your account with them), so that you can see and control payment transactions that your customers have made, make refunds, etc. You do not need to have a physical terminal and type credit card numbers into it and the whole thing is very secure.

 

Enough for now! :)

[♥Vger]

You do not ned to be PCI compliant to use Protx Direct. You don't store any credit card info at all with their system, it's all done by them. The customer remains on your website during the transaction, it's only the encrypted data which goes from you to Protx, Protx to your Bank, back to Protx, and then back to your site as payment made or not.

 

You have to have an SSL connection to Protx, for encryption of data, and you cannot connect without it.

 

If you sign up for one of their MOTO accounts (Mail Order, Telephone Order) then this also allows you to take card transactions over the phone and by mail using the terminal they provide.

 

Unless you have to order in the goods before you can despatch them then "Payment" is the method to choose, as this gives you the funds at the "Clearance" at the end of each day.

 

If there is a delay while you order in the goods then use "Authorise" which checks to see that the money is available but doesn't take it from the card until you declare the goods "Shipped".

 

The osCommerce Protx Direct module (v4.4) allows you to also do Refunds (Full or Partial) and to Void transactions from your osCommerce admin panel, without having to login to your Protx Terminal.

 

Vger

[HappyPappy]

You do not ned to be PCI compliant to use Protx Direct. You don't store any credit card info at all with their system, it's all done by them. The customer remains on your website during the transaction, it's only the encrypted data which goes from you to Protx, Protx to your Bank, back to Protx, and then back to your site as payment made or not.

Vger

 

With respect Vger, you are wrong.

 

Whether encrypted or not, if the site trasmits the PAN (prmary account number) to Protx then the site MUST have PCI DSS compliance.

 

Here is a quote from the PCI DSS istelf ...

 

"PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply".

 

SSL is only one of the requirements of PCI DSS. Using SSL to encrypt data does NOT mean the site doesn't need PCI DSS certification. The site will be TRANSMITTING credit card data to Protx so the site, its IP, hosting account, the hosting network all have to be PCI DSS compliant certified.

 

I am very sorry but that's the way it is and to confirm this you only need read the PCI DSS itself.

 

But if in further doubt, please ring Visa, Mastercard or Amex and they will confirm what is written in black and white in the PCI DSS itself.

 

Thanks

[♥Vger]

Payment Card Industry Data Security Standard (PCIDSS), encompasses the rules of an organisation set up by the card companies to develop a common strategy on card security over the Internet.

 

I am not wrong about Protx Direct. Whether your website and the server it is on has to pass a PCI scan depends entirely upon which UK Bank issues your Internet Merchant ID and individual rules they apply to individual websites. For instance:

 

1. If you use Protx Direct + your Internet Merchant ID is issued by Barclays Bank + your site sells goods considered to be high-value and high-risk of fraud then Barclays will insist on PCI compliance.

 

2. If you use Protx Direct + your internet Merchant ID is issued by Barclays Bank + what you sell is considered low-volume and low-risk the they won't insists on PCI compliance.

 

In the UK PCI Compliance is not law of the land as it is in the USA.

 

Credit Card companies have not enforced compliance in the UK because they know it would break their business - UK Banks just are not ready for it. It is not enshrined in UK Law, but there are various features of the Data Protection Act which deals with the storage of credit card details on shared servers.

 

Except for the USA where this is law it is not so black and white in the rest of the world. Even what is required to become PCI compliant depends on the individual scanning company - and they keep changing their parameters on a regular basis.

 

I deal with this issue on our own UK servers all the time.

 

One customer using Protx Direct who had been on a shared server which was PCI compliant had to move to their own dedicated server after the scanning company changed their rules which made it completely impossible to make a shared server PCI compliant. Other customers using Protx Direct with the same Bank but a different scanning company are okay on a PCI compliant shared server. Other customers with other Banks and using Protx Direct are okay on shared servers which have not been scanned for PCI.

 

Vger

[failsafe]

Darn it! :)

 

And there was me thinking that I'd now be able to switch to using Protx Direct without now having to get PCI compliance. Guess I'll just have to stick with Protx Form then. It's a big shame the credit card companies can't come up with a method of securing the transaction without all this PCI stuff.

 

It's been mentioned before (wasn't it by you Peter?) that a simple method would have been to use one of the little 'calculator-like' gizmos into which the user inserts their credit card and types in their PIN. We could then transmit their CC data without any hassles whatsoever, because we would be able to challenge with the 6 digit number provided by the bank, and the customer would then use that to reply with the 6 digit number output from their gizmo into which their card is inserted. That mechanism is as secure as using a Chip'n'Pin machine isn't it. Although the transaction would be encrypted just for good measure, it wouldn't technically have to be and would still be secure enough, surely. What a bunch of bozos run this whole mess!

 

To level the playing field, all card companies should supply the device to their customers and in order to shop on the net EVERYONE would have to use it. No question, no getting around it. No half cocked use of 3D and leaving it to the eCommerce folks to 'educate' their customers for them. They make enough money form transactions as it is. And, it would all but eradicate the fraud from eCommerce wouldn't it?

 

I've even got one of the gizmos now with my RBS account. When I lived in the Netherlands, ABN AMRO bank forced me to use one 8 years ago to do Internet banking on their site. It's hardly rocket science! And as for chip'n'pin, it took the UK years to introduce it here. Half of Europe had been using it years before the UK got around to it and you'd have thought the UK had invented it the way they advertised it and made it sound so complicated. The UK made it such a big deal!

 

Just my 2c. I'm fed up to the teeth of all this PCI crud and 3D secure mess. Oh and while I'm at it... why on earth don't they just force EVERYONE to use 3D secure right now? If you don't use 3D secure, you don't use your credit card online - no question. That wouldn't be difficult for the credit card companies to impose if they wanted to. Trouble is, they obviously don't really want it, especially since the poor retailer carries the fraud liability for them! Grrr. Where's my punch bag gone? :)

[failsafe]

Hey, I've got a wonderful idea! Why not ditch the whole gizmo 'calculator-like' device altogether and build the whole darn thing into the credit/debit card itself. I've had a wafer-thin credit card size solar powered calculator for years. So why not make something like that combined with a credit card. When someone wants to buy something online, they type in their PIN to their card and then when challenged by the 6 digit number from the bank they can type that in to their card and it comes back with the 6-digit translation for it. Sounds a lot more secure than 3D to me, and you don't have to remember any extra numbers than your normal PIN you use every day at the supermarket.

 

And what's more, the same system could be used for MOTO transactions, customer is given the 6 digit challenge number by the retailer over the phone and replies with the 6-digit translation to that number to the retailer who then is able to type it into their terminal.

 

Surely that would solve everyone's problem and also make cloning cards much more difficult since all issuers could use a different proprietary algorithm to translate the 6 digit number?

[♥toyicebear]

Yes a digital time limited code would make shopping with credit card, incredibly more secure..

 

It would also greatly reduce fraud for shop owners...

 

And the icing on the cake about such a system is that it would not mather if anyone tried to store such a code, since such codes are only valid for 30 seconds....

 

But things like that is something which might or might not come in the future, so for now lets get back to your more immediate problem.

 

If you want to store cc, then its very complicated to be PCI compliant....

 

But if you use an online payment gateway , the PCI compliancy you have to concern yourself about is fairly straightforward and easily done.

 

 

Info:

 

PCI Regulations

 

 

Step by step for being PCI Compliant with the use of a online payment gateway

[failsafe]

so for now lets get back to your more immediate problem.

 

If you want to store cc, then its very complicated to be PCI compliant....

 

But if you use an online payment gateway , the PCI compliancy you have to concern yourself about is fairly straightforward and easily done.

 

Thanks Nick (and Peter and Vger). I'll look into the free hackergardian service for PCI compliance. At the end of the day, it's probably safer for me to just use Protx VSP Form for now until the dust has settled. I've got a feeling that the Protx VSP Direct contribution would be OK too, but I'd have to then do something about PCI DSS compliance in some way. I'm sure most retailers with osCommerce shops just blindly ignore all this stuff though.

 

Thanks all.

[♥Vger]

When someone wants to buy something online, they type in their PIN to their card and then when challenged by the 6 digit number from the bank they can type that in to their card

But things like that is something which might or might not come in the future

 

Already using something similar for access to an online Business account. We have to type in our security code, and then we press a button on a little gizmo provided by the Bank which displays a new six digit number which we have to type in before being allowed to login.

 

Vger

[♥toyicebear]

Already using something similar for access to an online Business account. We have to type in our security code, and then we press a button on a little gizmo provided by the Bank which displays a new six digit number which we have to type in before being allowed to login.

 

Vger

 

 

Yes, its been available for online banking for years...

 

But a similar solution where this is used for credit card purchases has not seen the light of day yet. (The closest would be 3D secure and verified by visa).

 

 

A cc card with a electronic code maker built inn working basically the same way as the online banking code cards ... would be a great security feature for online shoppers and shops alike.

[HappyPappy]

I am not wrong about Protx Direct. Whether your website and the server it is on has to pass a PCI scan depends entirely upon which UK Bank issues your Internet Merchant ID and individual rules they apply to individual websites.

 

Vgar, you are very wrong. The banks (merchant account providers) also run the risk of fines if they are party to any activity by their merchants that is deemed not to be compliant with PCI DSS.

 

You are getting mixed up with risk assessment which helps determine the % rate. The % rate will be comensurate with the risk assessment which in turn is about what type of business you operate, how long you have been in operation etc etc. In actual fact it is a calculation that helps establish the banks risk exposure in providing the service to you.

 

The PCI DSS facts are ....

"PCI DSS requirements are applicable if a Primary Account Number (PAN) is stored, processed, or transmitted. If a PAN is not stored, processed, or transmitted, PCI DSS requirements do not apply".

 

You are tyring to tell people the actual definition in the PCI DSS itself is wrong and that Barclays thinks its OK not to have PCI DSS compliance in some circumstances. What you are saying is not only absolute rubbish, it is also very dangerious if anyone listens to it.

 

READ THE PCI DSS. It is a global standard.

 

If a customer is using Protx Direct but they do not have PCI DSS compliance for their website they are risking heavy fines and the cancellation of their merchant account facilities.

 

For goodness sake, please ring Visa International or Master Card and tell them Barclays will let you accept credit cards online using Protox Direct without your site being PCI DSS compliant and listen to them hit the roof!!!

 

I don't want to enter into an argument so to sum up my advice to anyone reading this, please take time to ring the offices of Visa, Mastercard and ask them. The facts are if your site touches credit card data in anyway you MUST have PCI DSS compliance. Facts are facts.

 

This is why I use e-path. I am totally covered with PCI because my site doesn't touch credit card data. Although e-Path is a manual system for offline processing (which happens to be perfect for me) I have full control over what I accept, its a lot cheaper and much more secure.

 

Thanks

[♥Vger]

This is why I use

 

I'm getting fed up with your blatant advertising of this payment processing company you are so in love (or in league) with.

 

Every single post you've made, except for your very first post ever, have been about PCI DSS and/or this payment company you are promoting - and you've included links to it in many of them.

 

I'll leave it up to others to decide whether:

 

1. They believe you with 21 posts, 20 of them promoting this one payment company, or

 

2. Believe me with 16,668 posts and no particular axe to grind - who just happens to run a highly successful hosting company that has to deal with PCI DSS issues on a regular basis.

 

Keep on promoting this payment company and I'll have to report you to forum moderators. They'd only have to scan the posts you've made to see the blatant promotion.

 

Vger

[accpacnet]

I just want to know if i dont want OS Commerce to save the full credit card no. as its storing it.

i want it to store only first four and last four digits for its identification.

 

how can I configure it that way ?

Regards

Shawn Nizar

[wider]

Hi!

 

There is a lot of speculation about Protx Direct on this forum.

Some say that you do and some that you don't require your site/server to be PCI compliant not.

 

I've finally had a clear statement from Protx:

 

If a vendor wishes to use VSP Direct we strongly recommend that they are as compliant with PCI regulations as possible, however, card scheme regulations are outlined below.

As you can see from the table, the level of compliance required is largely determined by the volume of transactions processed.

 

What the merchant must remember is that it's not purely the storing of card information which can lead to card data being compromised, but that any potential insecurity can be used to gain access to this data.

 

For example, if card information is captured briefly on the payment page, and then forwarded on to Protx, if this capturing stage is compromised then it is irrelevant that the merchant is not storing card information, as the data will be captured and stored by the intruder.

 

Protx has specifically created two solutions, VSP Form and VSP Server for vendors who do not wish to undergo thorough PCI compliance. Our API solution, VSP Direct, while being PCI Compliant itself, and verified by an independent qualified security assessor (Trustwave in this instance) does not automatically provide compliance for merchants capturing (and storing) card information on their own websites.

 

Merchants wishing to use VSP Direct will need to use the guidelines below as an indication as to what level of compliance they require:

 

 

Criteria Compliance Requirements

 

Level 1

 

More than 6 million transactionsannually

Annual onsite audit by a QSA

Quarterly network security scan

 

Level 2

 

1,000,000 - 5,999,999 transactions annually

Annual self assessment questionnaire

Quarterly network security scan

 

Level 3

 

20,000 to 1 million e-commerce transactions annually

Annual self assessment questionnaire

Quarterly network security scan

 

Level 4

 

Up to 20,000 e-commerce transactions annually

Recommended Annual self assessment questionnaire &

Quarterly network security scan

 

Validation requirements and dates for Level 4 merchants are determined by the merchant's acquirer. Submission of scan reports and/or questionnaires by level 4 merchants may be required.