PCI compliant manual payment gateway help

[tmccaff]

I am looking for a solution to accept credit cards on my site.

 

We need to manually run credit cards only since we actually have to run card from supplier. We are a travel agency, so if they bought a cruise from Carnival I have to run it there.

 

I seen the only one that would work for us is E-Path but expensive.

 

We are looking at solutions. Can we store credit card info in database securely and still be PCI compliant? My understanding is you can do it except can't allow the CVV code and once you run card you delete it off the database.

 

Or is there another payment gateway like E-path that would do it but cheaper.

 

Thanks

[Dan Cole]

@@tmccaff Did you ask your payment processor what payment gateways they work with?  I see you didn't indicate where you are located so it might be tough for anyone to give you specific suggestions based on what they are using.

 

Dan

[MrPhil]

Could you elaborate on what you mean by

 

We need to manually run credit cards only since we actually have to run card from supplier.

 

 

If I book a cruise in person on, say, Carnival, are you saying you have to run my Visa card through a POS terminal connected to Carnival (not to a bank)? That seems odd (unless all the lines share one terminal). If I book over the Internet, how would you be looking to handle my card? You're not charging cards and depositing proceeds to your own bank account (merchant account) and then passing on money to the cruise line? That is the standard way for merchants to sell things and accept credit cards over the Internet. You can also get Third Party payment systems (PayPal and others) who let you handle credit cards entirely on your site (the customer isn't taken offsite to enter their payment information), but you still have to meet PCI security requirements.

 

You can do almost anything with handling credit card information, so long as you're willing to spend (possibly) a lot of money meeting PCI security requirements. You'll be audited up the wazoo to see what kind of physical and remote access someone might get to your server and data. It's a lot more than just having SSL on the link and encryption on all stored data. Even when you become PCI certified, you will still need permission from your financial institution (whoever is playing that part) to run CC numbers obtained over the Internet on an in-store terminal. Since fraud rates are much higher over the Internet than in-person, they will want to charge higher fees to cover their expected losses due to fraud.

[tmccaff]

This is how I do it. Lets say you book on my  site a Carnival cruise. I go to Carnival put your info in and charge your card from Carnival. Carnival than sends me a commission check from the cruise. I have to charge to the supplier not to me. The only one that seems to work is E-Path it looks like.

[MrPhil]

So Carnival (e.g.) does the actual CC charge and you just pass them the CC info from your office? An odd setup, but whatever... They won't let you do the charging and then do an echeck or bank transfer to them (less your commission)? Do you currently call in the CC, or is there some sort of card reader or terminal?

 

It would be up to the various cruise lines, etc. who operate in this way, to define under what forms and controls they'll accept Internet-supplied CC numbers. The big question would be who is responsible for damages if there is a hack somewhere in the process and CC numbers are stolen. You'd better be sure that you're not left twisting in the wind when (not if) this happens. Also, if the card is stolen or fraudulent, are you on the hook for that?

 

In this day and age, they must already have experience in having customers reserve via the Internet with travel agents. If they claim not to, it's only because they want to cut out the middleman (you) and have customers book directly with them. Do they actually insist on having the CC themselves? I wouldn't try rigging up my own system -- see if you can use something that they are familiar with and approve of. If it's only E-Path, and it's too costly for you, that would be a problem.

 

By the way, where does osC enter into this process? Is it used as a catalog to display customer choices, and accept an order, and then the payment setup is very unusual?

[Enzo_UK]

I think it would be very hard (if not impossible) to do it and be PCI compliant...

 

The only way I can think of it working is that if the companies that want the payments handled like this actually supplied their own secure payment gateway, that the customer is redirected to for payment.

 

So customer browses your site, selects cruise, goes through to order, passes customer to secure payment page hosted by cruise company, pays cruise company directly, details that payment has been taken gets passed back to your site, and generates an order, and cruise company know the customer came from your site so you get your commission.

 

Its a bit odd from a legal perspective too, as its a bit of a muddle whos customer is actually whos?

 

As if you take the full payment from your customer, and then you pay cruise company... what if cruise company go bust in the mean time?  Your customer paid you, and will do a chargeback on their card as aren't getting a holiday, your left massively out of pocket as have no way of getting money back from cruise company.

 

If customer pays cruise company directly, then if cruise company go bust, its just down to the customer to try and get their money back.