The client I'm doing work for is pretty set on wanting to store credit
card information so users can buy stuff without having to type in the
CC information all the time. He knows that it's a PITA to do right,
but wants it done anyways.
So, here's my current thinking of it:
Two servers, the Rails db/app/web server and the CC secure server. The
CC server only talks to authorize.net and the Rails server.
Public key stored on the Rails db server. Order comes in with new CC
data. The important stuff gets encrypted using the public key. Rails
assigns some arbitrary id to the CC (for future reference) and
remembers the last 4 digits and expiry date of the CC. Rails sends the
encrypted information (maybe using DRb) to the CC server. The CC
server decrypts the information using its private key. It sends a
request to authorize.net to authorize the payment. The CC server
returns success or failure to the Rails server. Then the order is
placed or declined.
If an order comes in and the customer wants to reuse a previously-used
CC, the Rails server sends a request to the CC server with the
remembered arbitrary id for the CC.
There are ways around storing local CC data. With Verisign (aka Paypal) for instance, you can store a nondescript transaction id (PNREF) and then use that later when you need to recharge the same card. All the CC data is kept on Verisign’s servers, alleviating (most of) the liability off you.
I don’t know what vendor you’re using for CC processing, but I’d bet that most of the big players have a feature like this. I personally, would never store CC data unless I was absolutely forced to…that’s after switching CC vendors if necessary.
Really? More than the cost of doing all the compliance yourself, not to
mention the countless hours you seem to be spending on this? That's got to
add up pretty darn quick.
Really? More than the cost of doing all the compliance yourself, not to
mention the countless hours you seem to be spending on this? That's got to
add up pretty darn quick.
Yes. We did the math. I've probably only spent two or three hours on
this so far.
I’m going through some of what you are going through with one client. Although he hasn’t made a final decision three things that are hard to put a price on is the peace of mind at night, the liability in case somebody gets through and the time/money it takes to recover from such a blunder. Not even considering the lost business for the bad publicity after like that happens. Agree this last point affects you if somebody hacks into Citadel but it sure is a smaller hit if you are the culprit.
I'm going through some of what you are going through with one client.
Although he hasn't made a final decision three things that are hard to put a
price on is the peace of mind at night, the liability in case somebody gets
through and the time/money it takes to recover from such a blunder. Not even
considering the lost business for the bad publicity after like that
happens. Agree this last point affects you if somebody hacks into Citadel
but it sure is a smaller hit if you are the culprit.
Thanks!
I'd appreciate it if someone could tell me if there's anything wrong
with my approach.
One more question regarding TrustCommerce recurring billing…
Do they allow to pass subscription variables automatically?
ex: if the sale was a monthly or quarterly subscription?
With Authorize’s ABR the sale is made, the client’s card is charged
but the merchant has to login into Authorize.net admin
and setup the subscription options manually (start date, monthly/quarterly/yearly, trial offer)
