Storing credit card information... sigh

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.

That sound reasonable?

Just use TrustCommerce Citadel. They get to worry about doing it
right. :slight_smile:


Building an e-commerce site with Rails?
http://www.agilewebdevelopment.com/rails-ecommerce

I thouth it was illegal for vendors to hold on to customers credit card
details

On 8/31/06, Benjamin C. [email protected] wrote:

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.

That sound reasonable?

www.blogsaic.com
search, post, blog

It’s not illegal. You are simply liable.

Check the thread on PCI Certification which was spurred earlier this
month.

-NSHB

On 8/30/06, Dion H. [email protected] wrote:

server decrypts the information using its private key. It sends a
That sound reasonable?

www.blogsaic.com
search, post, blog


Nathaniel Steven Henry Brown

Open Source Insight - http://nshb.net
Open Source Development - http://inimit.com
Open Source Training - http://osevents.com

I believe that VISA has certain guidelines a vender must follow in
order to
be allowed to take that form of credit. MasterCard and others may as
well.

+! for TrustCommerce Citadel.

This is NOT something I would want to do myself.

oh, and be sure to sanitize your logs for cc numbers as well.

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.

Ed

Benjamin C. wrote:

Just use TrustCommerce Citadel. They get to worry about doing it
right. :slight_smile:

Too expensive.

Joe

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.

Joe,

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.

Just my .02c opinion,

Adrian M.

On 8/31/06, [email protected] [email protected] wrote:

right. :slight_smile:

Too expensive.

Joe


Adrian Esteban Madrid

Adrian M. wrote:

Joe,

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.

Joe

HH wrote:

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.

Joe

Hi Joe,

not sure if it has already been posted somewhere, but be sure to read
this:

http://blog.duncandavidson.com/2006/06/cautious_advice.html

cheers

Thibaut

Make sure to check out this prior thread on the same topic, if you
haven’t already:
http://wrath.rubyonrails.org/pipermail/rails/2006-August/060825.html

Cheers,
Steven L. (BDes Hons., Provisional RGD)
{
c = Steven L. Design;
w = http://www.stevenluscherdesign.com/
}

I believe the TrustCommerce pricing is similar to Authorize.net on
recurring billing.


Building an e-commerce site with Rails?
http://www.agilewebdevelopment.com/rails-ecommerce

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.

what’s the price range of TrustCommerce’s recurring billing?

http://www.authorize.net/solutions/merchantsolutions/merchantservices/automatedrecurringbilling/

Authorize.net charges a $40 setup fee
and additional $20/month to your monthly fees

This forum is not affiliated to the Ruby language, Ruby on Rails framework, nor any Ruby applications discussed here.

| Privacy Policy | Terms of Service | Remote Ruby Jobs