PHP DB - RE: [PHP-DB] Credit Card Encryption

Author

RE: [PHP-DB] Credit Card Encryption

Bastien Koert

2007-12-20, 4:00 am

Dan,

Normally I would completely agree, its our job to find those solutions. Unfortunately, the sector that my FT job deals with is retail and many of our clients are in this bind with PCI data. Hefty fines are charged to those not in compliance. The major CC companies are taking this so seriously and the ramifications are being felt in many IT shops. Compliance failure can lead to loss o privileges to accept CCs.

Its gonna force us to be more creative in how we handle the data and createthe applications that allow our clients to offer ecommerce, we will have to learn some business skills to make this happen. It may mean that its becomes more contractual in dealing with third parties, where the ecommece shopeffects payment on behalf of the vendors. The OP may need to help his client work out a better way to manage the transactions between the related parties by finding ways to automate the various transactions and provide gateway access...

I, too, like to eat... ;-P

bastien

> Date: Wed, 19 Dec 2007 17:21:57 -0500> From: parasane@gmail.com> To: bastien_k@hotmail.com> Subject: Re: [PHP-DB] Credit Card Encryption> CC: larentium@hosthive.com; php-db@lists.php.net> > On Dec 19, 2007 4:45 PM, Bastien Koert <bastien_k@hotmail.com> wrote:> >> > Nope, I still would not recommmend it. The only place the CC data should travel to is the payment gateway. Anything else is a security risk. Why does your client process by hand? They should be using a payment gateway.> > That's true, Bastien, but if for whatever reason it's not an> option for them, what? Tell them it's tough cookies and they're SOL?> > Our job as programmers - especially freelance - is to make things> happen as safely and securely as we can, but as a bottom line, make it> happen. I'm sure we (most of us) take the responsibility to> discourage a client from making such choices, and to educate them on> alternatives that are better for their interests, but still - at the> end of the day, we're still just code monkeys. We're expected to> build what the client needs, or else they'll find someone else to do> it for them.> > And I don't really like to go hungry. ;-)> > -- > Daniel P. Brown> [Phone Numbers GoHere!]> [They're Hidden From View!]> > If at first you don't succeed, stick to what you know best so that you> can make enough money to pay someone else to do it for you.
________________________________________
_________________________
Exercise your brain! Try Flexicon!
http://puzzles.sympatico.msn.ca/chi...ml?icid=htmlsig

Gary Wardell

2007-12-20, 4:00 am

Hmm,

This is kind of throwing a new twist on things.

When it comes to liability, who is liable, the merchant running the system, the develper that created the system, or both?

If the develper is included, would that be mitigated in that he created the system to the merchant's specifications?

Also, in terms of the developer, would this be covered under errors and omissions insurance, or would they take the position that
the developer should have known better and was negligent in creating a non-compliant system leaving the developer on the hook for
damages?

Gary

> -----Original Message-----
> From: Bastien Koert [mailto:bastien_k@hotmail.com]
> Sent: Wed, December 19, 2007 11:02 PM
> To: Daniel Brown
> Cc: Keith Spiller; php-db@lists.php.net
> Subject: RE: [PHP-DB] Credit Card Encryption
>
>
>
> Dan,
>
> Normally I would completely agree, its our job to find those
> solutions. Unfortunately, the sector that my FT job deals
> with is retail and many of our clients are in this bind with
> PCI data. Hefty fines are charged to those not in compliance.
> The major CC companies are taking this so seriously and the
> ramifications are being felt in many IT shops. Compliance
> failure can lead to loss o privileges to accept CCs.
>
> Its gonna force us to be more creative in how we handle the
> data and create the applications that allow our clients to
> offer ecommerce, we will have to learn some business skills
> to make this happen. It may mean that its becomes more
> contractual in dealing with third parties, where the ecommece
> shop effects payment on behalf of the vendors. The OP may
> need to help his client work out a better way to manage the
> transactions between the related parties by finding ways to
> automate the various transactions and provide gateway access...
>
> I, too, like to eat... ;-P
>
> bastien
>
>
> parasane@gmail.com> To: bastien_k@hotmail.com> Subject: Re:
> [PHP-DB] Credit Card Encryption> CC: larentium@hosthive.com;
> php-db@lists.php.net> > On Dec 19, 2007 4:45 PM, Bastien
> Koert <bastien_k@hotmail.com> wrote:> >> > Nope, I still
> would not recommmend it. The only place the CC data should
> travel to is the payment gateway. Anything else is a security
> risk. Why does your client process by hand? They should be
> using a payment gateway.> > That's true, Bastien, but if for
> whatever reason it's not an> option for them, what? Tell them
> it's tough cookies and they're SOL?> > Our job as programmers
> - especially freelance - is to make things> happen as safely
> and securely as we can, but as a bottom line, make it>
> happen. I'm sure we (most of us) take the responsibility to>
> discourage a client from making such choices, and to educate
> them on> alternatives that are better for their interests,
> but still - at the> end of the day, we're still just code
> monkeys. We're expected to> build what the client needs, or
> else they'll find someone else to do> it for them.> > And I
> don't really like to go hungry. ;-)> > -- > Daniel P. Brown>
> [Phone Numbers Go Here!]> [They're Hidden From View!]> > If
> at first you don't succeed, stick to what you know best so
> that you> can make enough money to pay someone else to do it for you.
> ________________________________________
_________________________
> Exercise your brain! Try Flexicon!
> http://puzzles.sympatico.msn.ca/chi...ml?icid=htmlsig

Bastien Koert

2007-12-20, 4:00 am

Gary,

I take the view that I warn our customers about the dangers, and if really concerning ask for an indemnity or a very formal request for change. I really try to convince them of the correct path and keep any emails regarding the issues as backup

Its a drag when you really have to consider how to cover your ass on this. Lawyers suck too. ;-P

bastien> From: gwardell@gwsystems.co.il> To: bastien_k@hotmail.com> CC: php-db@lists.php.net> Subject: RE: [PHP-DB] Credit Card Encryption> Date: Wed,19 Dec 2007 23:21:52 -0500> > Hmm,> > This is kind of throwing a new twiston things.> > When it comes to liability, who is liable, the merchant running the system, the develper that created the system, or both?> > If the develper is included, would that be mitigated in that he created the system to the merchant's specifications?> > Also, in terms of the developer, would this be covered under errors and omissions insurance, or would they take the position that> the developer should have known better and was negligent in creating a non-compliant system leaving the developer on the hook for> damages?> > Gary> > > -----Original Message-----> > From: Bastien Koert [mailto:bastien_k@hotmail.com]> > Sent: Wed, December 19, 2007 11:02 PM> > To: Daniel Brown> > Cc: Keith Spiller; php-db@lists.php.net> > Subject: RE: [PHP-DB] Credit Card Encryption> >> >> >> > Dan,> >> > Normally I would completely agree, its our job to find those> > solutions. Unfortunately, the sector that my FT job deals> > with is retail and many of our clients are in this bind with> > PCI data. Hefty fines are charged to those not in compliance..> > The major CC companies are taking this so seriously and the> > ramifications are being felt in many IT shops. Compliance> > failure can lead to loss o privileges to accept CCs.> >> > Its gonna force us to be more creative in how we handle the> > data and create the applications that allow our clients to> > offer ecommerce, we will have to learn some business skills> >to make this happen. It may mean that its becomes more> > contractual in dealing with third parties, where the ecommece> > shop effects payment on behalf of the vendors. The OP may> > need to help his client work out a better way to manage the> > transactions between the related parties by finding ways to> > automate the various transactions and provide gateway access...>>> > I, too, like to eat... ;-P> >> > bastien> >> >> > > Date: Wed, 19 Dec2007 17:21:57 -0500> From:> > parasane@gmail.com> To: bastien_k@hotmail.com> Subject: Re:> > [PHP-DB] Credit Card Encryption> CC: larentium@hosthive.com;> > php-db@lists.php.net> > On Dec 19, 2007 4:45 PM, Bastien> > Koert <bastien_k@hotmail.com> wrote:> >> > Nope, I still> > would not recommmend it. The only place the CC data should> > travel to is the payment gateway. Anything else is a security> > risk. Why does your client process by hand? They should be> > using a payment gateway.> > That's true, Bastien, but if for> > whatever reason it's not an> option for them, what? Tell them> > it'stough cookies and they're SOL?> > Our job as programmers> > - especially freelance - is to make things> happen as safely> > and securely as we can, but as a bottom line, make it>> > happen. I'm sure we (most of us) take the responsibility to>> > discourage a client from making such choices, and to educate> > them on> alternatives that are better for their interests,> > but still - at the> end of the day, we're still just code> > monkeys. We're expected to> build what the client needs, or> > else they'll find someone else to do> it for them.> > And I> > don't really like to go hungry. ;-)> > -- > Daniel P. Brown>> > [Phone Numbers Go Here!]> [They're Hidden From View!]> > If> > at first you don't succeed, stick to what you know best so> > that you> can make enough money to pay someone else to do it for you.> > ________________________________________
_________________________> > Exercise your brain! Try Flexicon!> > http://puzzles.sympatico.msn.ca/chi...ml?icid=htmlsig>
________________________________________
_________________________
Exercise your brain! Try Flexicon!
http://puzzles.sympatico.msn.ca/chi...ml?icid=htmlsig

Daniel Brown

2007-12-20, 9:59 pm

On Dec 19, 2007 11:59 PM, Bastien Koert <bastien_k@hotmail.com> wrote:
> I take the view that I warn our customers about the dangers, and if really concerning ask for an indemnity or a very formal request for change. I really try to convince them of the correct path and keep any emails regarding the issues as backup

I was going to say the same thing. If PCI is really becoming that
big of an issue where there's even the slightest threat of backlash to
the developer, an indemnification clause (Santa's European cousin)
should probably be the course of action. That said, I think I'm going
to peruse the compliance information at that link you sent earlier.

--
Daniel P. Brown
[Phone Numbers Go Here!]
[They're Hidden From View!]

If at first you don't succeed, stick to what you know best so that you
can make enough money to pay someone else to do it for you.

Sponsored Links