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.
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.
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.
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.
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)
which is not the most efficient way to do it.
