[ic] User options
kevin at cursor.biz
Thu Apr 6 11:58:25 EDT 2006
Bill Carr <bill at worldwideimpact.com> wrote:
> On Apr 5, 2006, at 9:29 PM, Elver Loho wrote:
> > We're using 5.0 with some custom patches. Right now the client can
> > enter his/her credit card number during checkout and it'll be
> > remembered by the system for when he/she is buying something again.
> > What we'd like to do is make it so that the client can change the
> > credit card number in his/her settings as well. The problem is that
> > Interchange has hidden that part of the code... Somewhere. I'm not
> > sure where it is. Just copying that part over from the checkout code
> > enables changing the credit card details, but not creating them. It
> > fails to set mv_credit_card_reference in userdb, plus it doesn't send
> > over the CC# in an encrypted e-mail as is usual.
> > Could someone point me in the right direction in this regard here?
> Sorry I don't have an answer but I am glad you brought it up. I think
> Interchange does not save the CC number for security reasons. We have
> not been storing credit card numbers but would like to be able to do
> the following:
> 1. Allow the user's payment details to remembered as you mention
> above. This is becoming a standard for major e-commerce site's (i.e.
> Amazon.com, Apple.com, etc.).
> 2. Eliminate the need to send the PGP encrypted credit card number
> via e-mail. This is a confusing part of the process for the merchants
> we are doing sites for that I would like to eliminate. We are
> currently directing our customers to setup the encryption using
> Windows Privacy Tools. We would like to let the merchant see the CC
> number on the order detail screen and/or give them the ability to
> download a batch of orders for import into their POS/Accounting
> system. This transfer would happen via https.
> 3. Manage recurring billing (i.e. Wine Clubs)
> Question: What are the best practices for handling the credit card
> numbers for the purposes mentioned above? For years I've been telling
> clients we never store credit card numbers. That has been a very
> convenient way to manage our liability but I don't think we are going
> to be able to get away with it for much longer. The consumer expects
> both convenience and security. What is the right way to do both?
Interchange is coded to be very careful with credit card numbers and,
although bypassing this is easy, none of the members of the Interchange
development group will provide hints at all. Having said that, it
should be possible to come up with a solution to the above that does
not require card numbers to be stored on the server.
For instance, when the user enters a card number, you could create
a token (perhaps a random value) and a description (i.e. 12**3456)
to reference the card.
The token and the actual card number can be sent to the merchant,
with full encryption, who can then be responsible for the storage
and security of the card details. The token and description can be
stored in a table on the server.
If the user wants to change the card number then the following is
1. Present the list of card descriptions held against the
2. Allow the user to enter a new card number.
3. Update the description (now 45**6789) as a reminder of
the card number, and update the row in the database using
the original token as the row key.
4. Send the new card number and the token to the merchant
with full encryption. The merchant can then update the
card number, held against that token, in their local list.
If a user needs to re-use a card number, they can be presented with
a list of card descriptions. Only the token needs to be sent to the
merchant, who can use it to look up the card number. The merchant
will need to process the card number locally, as no card number will
be available on the server for use with an automatic payment submission.
Recurring orders can be handled locally. Details of the order, or
changes to it, can be sent from the server with a card token attached.
If some script kiddie cracks the server then all they'll find is a
bunch of random tokens and some descriptions. They may still have
enough personal information (names, addresses, phone numbers and
details of past orders etc.) to go phishing for more, so you still
need to keep your server as secure as possible.
Note that if a merchant wants to store credit card numbers, even locally,
then they must comply with the full set of security requirements that
are insisted upon by the likes of Visa and Mastercard. You could have
your merchant account withdrawn, and worse, if you're found to be
storing this sensitive information in a credit_cards.txt file.
Also note that if you create your own forms to handle updates to card
details then you will need to be very careful with the form fields you
use. Among other precautions, you must ensure that the values are not
written to disk at any time. Remember that the user's session is stored
on the server (in a file or database table), so the values must be
deleted before the session is written. You cannot rely upon the next
page cleaning up the session, as the user might not get that far.
Disclaimer: I have never done any of the above, so a lot more thought
would need to go into this before any of it could be implemented. It
would be best to run your proposed plan and security arrangements past
Visa, Mastercard and/or your merchant account provider before
implementation of your plans. Don't blame me if you follow the above
to the letter and someone from Visa kicks your door in. :-)
_/ _/ _/_/_/_/ _/ _/ _/_/_/ _/ _/
_/_/_/ _/_/ _/ _/ _/ _/_/ _/ K e v i n W a l s h
_/ _/ _/ _/ _/ _/ _/ _/_/ kevin at cursor.biz
_/ _/ _/_/_/_/ _/ _/_/_/ _/ _/
More information about the interchange-users