Обсуждение: How to design a "customer" TABLE which hold credit card infos and other payments?

Поиск
Список
Период
Сортировка

How to design a "customer" TABLE which hold credit card infos and other payments?

От
Michelle Konzack
Дата:
************************************************************************
*       Do not Cc: me, because I READ THIS LIST, if I write here       *
*    Keine Cc: am mich, ich LESE DIESE LISTE wenn ich hier schreibe    *
************************************************************************

Hello,

I am coding a new OnlineStore (the existing ones fit not my  needs,  are
to complicate to use or simply closed  source  and  too  expensive  e.g.
InterShop) with an integrated powerful ledger.

So now it comes to infos about Credit Cards, PayPal and friends...

Does someone have an experience with it

    1)  how I should store it
    2)  how the TABLE fields should look like

And yes, I would use a reference to external tables  instead  of  puting
those data in the main "customer" TABLE...

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
+49/177/9351947    50, rue de Soultz         MSN LinuxMichi
+33/6/61925193     67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Вложения

Re: How to design a "customer" TABLE which hold credit card infos and other payments?

От
"Scott Marlowe"
Дата:
On Thu, Nov 6, 2008 at 2:43 PM, Michelle Konzack
<linux4michelle@tamay-dogan.net> wrote:
> ************************************************************************
> *       Do not Cc: me, because I READ THIS LIST, if I write here       *
> *    Keine Cc: am mich, ich LESE DIESE LISTE wenn ich hier schreibe    *
> ************************************************************************

Sorry, it's how this list works.  If you don't want that, there are
some options for majordomo you can set to alleviate the issue.  I'm
not changing how I reply to the list just for you.

> Hello,
>
> I am coding a new OnlineStore (the existing ones fit not my  needs,  are
> to complicate to use or simply closed  source  and  too  expensive  e.g.
> InterShop) with an integrated powerful ledger.
>
> So now it comes to infos about Credit Cards, PayPal and friends...

If you are storing credit card data then you must follow the PCI
standards for doing so.  Look them up on the web and get a copy.
Failure to follow their security guidelines will result in you not
being allowed to process or handle credit cards.

That said, the best way to store them is to not store them.  If you
still have to, then use some kind of encryption using the user's
password as part of the key, and don't store the user's password, only
an md5 of it.  Also, store the password on one machine, encrypted, do
the encryption decryption on another machine.

Re: How to design a "customer" TABLE which hold credit card infos and other payments?

От
Andrei Kovalevski
Дата:
Hello,

Scott Marlowe wrote:
On Thu, Nov 6, 2008 at 2:43 PM, Michelle Konzack
<linux4michelle@tamay-dogan.net> wrote: 
************************************************************************
*       Do not Cc: me, because I READ THIS LIST, if I write here       *
*    Keine Cc: am mich, ich LESE DIESE LISTE wenn ich hier schreibe    *
************************************************************************   
Sorry, it's how this list works.  If you don't want that, there are
some options for majordomo you can set to alleviate the issue.  I'm
not changing how I reply to the list just for you.
 
Hello,

I am coding a new OnlineStore (the existing ones fit not my  needs,  are
to complicate to use or simply closed  source  and  too  expensive  e.g.
InterShop) with an integrated powerful ledger.

So now it comes to infos about Credit Cards, PayPal and friends...   
If you are storing credit card data then you must follow the PCI
standards for doing so.  Look them up on the web and get a copy.
Failure to follow their security guidelines will result in you not
being allowed to process or handle credit cards.

That said, the best way to store them is to not store them.  If you
still have to, then use some kind of encryption using the user's
password as part of the key, and don't store the user's password, only
an md5 of it.  Also, store the password on one machine, encrypted, do
the encryption decryption on another machine
Try to avoid storing any card and card holder info, and you definitely shouldn't keep in DB the whole data required to authorize transaction. Just take in mind how dangerous this info could be in case of security leak.
-- 
Andrei Kovalevski
PostgreSQL Replication, Consulting, Custom Development, 24x7 support
Managed Services, Shared and Dedicated Hosting
Co-Authors: PL/php, ODBCng - http://www.commandprompt.com/

Re: How to design a "customer" TABLE which hold credit card infos and other payments?

От
"Scott Marlowe"
Дата:
Oh, btw, the wikipedia page on the PCI standard I mentioned

http://en.wikipedia.org/wiki/PCI_DSS

Re: How to design a "customer" TABLE which hold credit card infos and other payments?

От
Michelle Konzack
Дата:
Am 2008-11-07 07:48:25, schrieb Scott Marlowe:
> On Thu, Nov 6, 2008 at 2:43 PM, Michelle Konzack
> <linux4michelle@tamay-dogan.net> wrote:
> > ************************************************************************
> > *       Do not Cc: me, because I READ THIS LIST, if I write here       *
> > *    Keine Cc: am mich, ich LESE DIESE LISTE wenn ich hier schreibe    *
> > ************************************************************************
>
> Sorry, it's how this list works.  If you don't want that, there are
> some options for majordomo you can set to alleviate the issue.  I'm
> not changing how I reply to the list just for you.

Again<seufz> look in the header of my message and  you  see,  my  access
provider is the german GSM provider O2 and my resources are limited.

I have the list set to "nomail" and it works fine, but  peoples  do  not
stop CCing/Bombing me an on all messages...

I READ THIS LIST and several dozen others too otherwise I would not able
to read this list!

> If you are storing credit card data then you must follow the PCI
> standards for doing so.  Look them up on the web and get a copy.
> Failure to follow their security guidelines will result in you not
> being allowed to process or handle credit cards.

OK, if I look into
    <http://en.wikipedia.org/wiki/PCI_DSS>

I fullfill this requirements since over 9 years since I was working many
years for the french Ministry of Defense...  :-/

> That said, the best way to store them is to not store them.  If you
> still have to, then use some kind of encryption using the user's
> password as part of the key, and don't store the user's password, only
> an md5 of it.  Also, store the password on one machine, encrypted, do
> the encryption decryption on another machine.

My idea is to use a second "computer" to store the  CC  data...  like  a
small Freescale i.MX31 (has  a  ATA-6  interface  for  HDD  and  support
cryption)

However, I do not realy know, HOW to design the database to hold data of
different Credit Cards...

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
+49/177/9351947    50, rue de Soultz         MSN LinuxMichi
+33/6/61925193     67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Вложения

Re: How to design a "customer" TABLE which hold credit card infos and other payments?

От
Michelle Konzack
Дата:
Am 2008-11-07 17:22:22, schrieb Andrei Kovalevski:
> Try to avoid storing any card and card holder info, and you definitely
> shouldn't keep in DB the whole data required to authorize transaction.
> Just take in mind how dangerous this info could be in case of security leak.

Yeah, at the German telecom there have peoples stolen 12 million records...
OK, not Credit Card infos, but personal customer data.

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
+49/177/9351947    50, rue de Soultz         MSN LinuxMichi
+33/6/61925193     67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Вложения

Re: How to design a "customer" TABLE which hold credit card infos and other payments?

От
Michelle Konzack
Дата:
Am 2008-11-07 09:53:07, schrieb Scott Marlowe:
> Oh, btw, the wikipedia page on the PCI standard I mentioned
>
> http://en.wikipedia.org/wiki/PCI_DSS

I know already...

But my question was about the Database Design to store the infos...

Thanks, Greetings and nice Day/Evening
    Michelle Konzack
    Systemadministrator
    24V Electronic Engineer
    Tamay Dogan Network
    Debian GNU/Linux Consultant


--
Linux-User #280138 with the Linux Counter, http://counter.li.org/
##################### Debian GNU/Linux Consultant #####################
Michelle Konzack   Apt. 917                  ICQ #328449886
+49/177/9351947    50, rue de Soultz         MSN LinuxMichi
+33/6/61925193     67100 Strasbourg/France   IRC #Debian (irc.icq.com)

Вложения

Re: How to design a "customer" TABLE which hold credit card infos and other payments?

От
"Scott Marlowe"
Дата:
On Sat, Nov 8, 2008 at 6:14 PM, Michelle Konzack
<linux4michelle@tamay-dogan.net> wrote:
> Am 2008-11-07 09:53:07, schrieb Scott Marlowe:
>> Oh, btw, the wikipedia page on the PCI standard I mentioned
>>
>> http://en.wikipedia.org/wiki/PCI_DSS
>
> I know already...
>
> But my question was about the Database Design to store the infos...

Well, don't those two things seem inextricably intertwined with each
other?  Anyway, I did post that in another message, which received no
response from you.