"Peter Beckman" <[EMAIL PROTECTED]> wrote in message
> On Fri, 6 Jan 2006, Dan Baker wrote:
>> "Peter Beckman" <[EMAIL PROTECTED]> wrote in message
>> news:[EMAIL PROTECTED]
>>> So I'm thinking about how to save credit card numbers in the DB, for
>>> re-charging cards for subscriptions, new orders, etc.
>>> I'm also thinking about how to save passwords in the DB, not plaintext,
>>> not one-way encrypted either.
>>> Any suggestions? How would I secure the database? I'm thinking some
>>> abstract process in code, or something -- security through obscurity.
>> [Summary: Call Verisign, pay THEM to store credit cards for you]
> What, exactly, does VeriSign do, that makes you so sure that they have
> secured the credit card information any better than I could, using a
> well-thought-out system? Do you even know? You just hear "VeriSign" and
> believe they have smart people that have more resources available to them
> to do a better job securing the data?
> Maybe this makes sense if you are doing a few hundred or a few thousand
> dollars of business a month, but if you are planning on doing $5,000 to
> $10,000 a day, it is a lot of added expense to have someone else do it,
> when I could have it done internally. It is the how.
> Please, no more replies saying don't do it.
VeriSign (and other similar organizations) have pro's and con's. Obviously,
the con's are usually tied to the big $.
VeriSign costs $70/month (for the first 1000 transactions per month). My
company is in the 1000 transaction per month range, but I think each
transaction after that is $0.10. BTW, VeriSign was just bought by PayPal.
You have to pay every credit card company you do business with, no mater
what solution to select. Usually a % of the total charges. If you do
enough business per card, your % drops. Also, if you don't include enough
information with each transaction, your % will be increased. The most
important information you need to include is: billing address and billing
zip code -- most credit card company's won't increase your % if you provide
these two pieces of information per transaction. CSC's (CVV2) are usually
not tied to your % payment, and it is illegal to store them.
You ask: "What exactly does VeriSign do?" I don't know. I pay them $70
each month, and they process my credit cards. I know they have been in the
business a long time, and experience means a lot (to me). Some how, I can
re-run a charge on an already-run credit card, and they magically know all
the information for that credit card (including the CSC). We sell a service
that people pay monthly for, and we make up the $70 to VeriSign in reduced
You mentioned that it "makes sense if you are doing a few hundred dollars a
month". This seems backward to me. It is too expensive if you only doing a
few hundred dollars a month. The $70 a month disappears as you do *more*
business. If you are doing $10,000 a day, you need to call each credit card
company you do business with (Amex, Discover) and ask for a "Rate Review".
They will surely drop their % if you are doing that kind of volume. We just
had a rate review with Amex, and our rate dropped significantly.
Oh --- You also need to check on your merchant account. They usually hit
you per transaction. This is were the $ can start to add up! Your merchant
account may also be handing your Visa/MC transactions, and taking a % of
those -- so ask for a rate review from them also.
And last of all, I know of a pretty large company that uses a service
similar to VeriSign. This other service (can't remember the name) didn't
provide the "PNRef" scenario, so the company stores credit card numbers in
their database (encrypted of course), and they just run the numbers every
month for their service. Seems to be working ok for them. I don't know who
wrote their software, what encryption they are using, where the data is
stored, how it is backed up -- I guess I don't know anything except they are
storing credit card numbers and are currently doing a good business. Funny,
they are still paying for a similar service to VeriSign.
PHP Database Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php