So I thought I would ask the CF community - how best to
handle receipt of credit card information.
I look forward to receiving replies on ways to approach this issue.
AFAIK, you are liable to getting big fines from the CC companies if you are
caught storing CC details these days. With the
AFAIK, you are liable to getting big fines from the CC companies if you are
caught storing CC details these days. With the payment gateways these days
there is *NO* need to store CC details.
You may like to take a look at https://www.pcisecuritystandards.org/
Paul
I'd say it's if you store
One-way encryption
-Original Message-
From: Pete [mailto:[EMAIL PROTECTED]
Sent: Monday, February 19, 2007 2:12 PM
To: CF-Talk
Subject: Credit Cards - How to handle
Hi there
I have a client that has instructed me that he must be able
to have client
credit card details
Here is what you can use. Just remember you'll need 2 for redundancy
http://www.ncipher.com/
http://www.ncipher.com/cryptographic_hardware/hardware_security_modules/10/nethsm/
PCI requirement if you are going to store customer info.
Eric
With the payment gateways these days
there is *NO* need to store CC details.
The need is determined by the online customer and merchant. Online
merchants want to be able to allow their customers to save their credit card
number for easier checkout when they return. In this case numbers need
I have a friend with an e-comm site where the developers had a security breach
with CC numbers.
Then it was audit time, and things got ULY!!!
Will
~|
Upgrade to Adobe ColdFusion MX7
Experience Flex 2
The need is determined by the online customer and merchant. Online
merchants want to be able to allow their customers to save their credit card
number for easier checkout when they return. In this case numbers need to
be stored.
Nope...processors allow for recurring billing AND the simple
2007 7:45 AM
To: CF-Talk
Subject: Re: Credit Cards - How to handle
Here is what you can use. Just remember you'll need 2 for redundancy
http://www.ncipher.com/
http://www.ncipher.com/cryptographic_hardware/hardware_security_modules/10/n
ethsm/
PCI requirement if you are going to store customer
I have had a couple requests like this and I generally keep
5446 7086
In the Database and send the middle 8 via email. Doesn't really make you
compliant because if they hack the server
and you haven't checked your mail some people will be compromised(if on
shared hosting where mail and
Basically they are not wanting to process credit cards through a payment
processor but they expect customers to order good regularly so want to be
able to have credit card details so they can handle when required.
Regards
Any suggestions thoughts
Use apayment processor and let them store
With the payment gateways these days
there is *NO* need to store CC details.
The need is determined by the online customer and merchant.
Online merchants want to be able to allow their customers to
save their credit card number for easier checkout when they
return. In this case
Nope...processors allow for recurring billing AND the simple storage of cc
details for future purchases...they give you their customer number and you
store
that against the clients record in your system.pass it back to them
for
future purchases.
Bryan, have you done this (retrieving a
Bryan, have you done this (retrieving a stored credit card number via a
customer number) with Authorize.net? I don't see anything in their API that
allows for that.
-- Josh
Nope...last time I dealt with them was the last time I will ever deal with them
(and this was when this type of
That is quite wrong. Most payment gateways these days issue a token
against
a credit card payment that you can re-use to re-bill. You never need to
see
the credit card number after the first transaction for this to work. I
believe the token is usually valid for a maximum of 13 months.
Auth.Net does offer ARB (Automatic Recurring Billing) but I believe it costs
more and required manually setting the txn to reoccur. This doesnt help a
company that wants to offer rebilling.
Alot of webhost billing systems have their own way to encrypt CC Info ,AWBS
for instance. Advantage is
What if this token that gets issued falls into the wrong
hands? If you don't need anything else but that token to
authorize a transaction, that's less secure than requiring a
cvv number for every transaction.
There's more to it than just a token but for the sake of this conversation,
I've never used Authorize.net although I've looked at it once or
twice but I never felt confident about actually integrating with them from
everything I read... Just a gut feeling that it would be more hassle than it
was worth...
BINGO...IMHO
Bryan Stevenson B.Comm.
VP Director of E-Commerce
Really? I have only seen one (Bank of America) about two years ago
and it was against that one. I've seen this mentioned before and it
was mentioned earlier in this thread again by someone claiming direct
experience. You've certainly done more of a few of these so I
respect your word on
The CCV/AVS validation is usually optional in your merchant account
settings, you can enable/disable it.
Correct, it's optional...but use of it reduces fraud, and often using it
reduces the merchant's rate as well.
--- Mary Jo
Address and card code are checked but come
back as extra information that a lot of the merchants don't use.
You usually can configure in the settings for the gateway how to use the
address verification and card code. You can set it to reject orders that fail a
certain way, and it can be used
I just implemented authorize.net's fraud detection suite. A scam artist got a
few sales thru our processor which incurred hundreds of $$ in chareback fees.
It was ridiculous.
The suite is $5/month and works really nice. It has lots more settings to
filter sales with. Plus it has its own
One of the things you have to remember about credit card is that not every
client is at the same level with using them. We have one client who just
started accepting credit cards this year. Their Biggest concern was the BIG
FEES on taking credit cards. If we started to talk about adding an
Hi all,
Thanks for all the advice.
I did have one idea I thought might work nicely alongside this... I was
contemplating sending part of the CC number via email and storing the rest of
it encrypted in the database?
Is this a worthwile positive step?
Richard
: Tuesday, September 26, 2006 10:39 AM
To: CF-Talk
Subject: Re: credit cards
On 9/26/06, Richard Cooper [EMAIL PROTECTED] wrote:
Is this a worthwile positive step?
Honestly... no. If it was, everyone would do it. All you've done is
make the hacker work just a little harder, and its clearly
On 9/26/06, Richard Cooper [EMAIL PROTECTED] wrote:
Is this a worthwile positive step?
Honestly... no. If it was, everyone would do it. All you've done is
make the hacker work just a little harder, and its clearly nowhere
near anything regarded as an acceptable practice.
Let me guess: the
Matt,
First of all, let me re-iterate what I said earlier in reply to the
original post - that I think storing the cards in the database in
any method is a bad idea.
The idea, in my example, is that one of the keys, the
customerSpecificKey can be stored in the database (i.e. - the
Matt,
First of all, let me re-iterate what I said earlier in reply to the
original post - that I think storing the cards in the database in
any method is a bad idea.
Now I've missed this whole thread, but I definately agree that storing card
numbers should be avoided at all
I think it was pointed out somewhere in this thread that storing cc
numbers at all is a violation of the merchant's card use agreement.
If they are just going to do it anyway, make sure you are covered from
the lawsuits that are likely to spring out of this horrible idea.
While I agree it is not
-Original Message-
From: Mary Jo Sminkey [mailto:[EMAIL PROTECTED]
Sent: Tuesday, September 26, 2006 2:34 PM
To: CF-Talk
Subject: Re: credit cards
I think it was pointed out somewhere in this thread that storing cc
numbers at all is a violation of the merchant's card use agreement
On 9/26/06, Jon Clausen [EMAIL PROTECTED] wrote:
The idea, in my example, is that one of the keys, the
customerSpecificKey can be stored in the database
OK I get it. The idea being the db server is a separate server and
would need a separate hack.
On 9/26/06, Mary Jo Sminkey [EMAIL PROTECTED]
On 9/26/06, Mary Jo Sminkey [EMAIL PROTECTED] wrote:
While I agree it is not a great idea, it certainly is not against the
card use agreements.
Really? I have only seen one (Bank of America) about two years ago and it was
against that one. I've seen this mentioned before and it was
The CCV/AVS validation is usually optional in your merchant account
settings, you can enable/disable it.
-
Snake
-Original Message-
From: Russ [mailto:[EMAIL PROTECTED]
Sent: 26 September 2006 20:28
To: CF-Talk
Subject: RE: credit cards
How many places actually check the card code
You're not using a payment processor, I assume?
-Original Message-
From: Richard Cooper [mailto:[EMAIL PROTECTED]
Sent: Monday, September 25, 2006 12:27 PM
To: CF-Talk
Subject: credit cards
Hi,
With a site that has a SSL and a form, what is the best way to get the
credit card
Ideally you should use an online Credit Card Processor such as Authorize.net,
in this case you do not need to store or send the CC details to anyone.
However, as is so often the case, the customer is not willing to spend the
money to use such a service. Given that scenario, you should NEVER SEND
Thats right. The payment processing is done by my clients accounts team.
R
~|
Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting,
up-to-date ColdFusion information by your peers, delivered to your door
Richard,
I highly advise against storing credit card information in your
database, if you can help it.It's a liabiltiy issue for you and/
or your client.
If you're using a payment processor, they can handle that for you
once you're transmitted the card data. Both Verisign and
Thanks. That makes a lot of sense.
R
~|
Introducing the Fusion Authority Quarterly Update. 80 pages of hard-hitting,
up-to-date ColdFusion information by your peers, delivered to your door four
times a year.
Oops. Didn't see Alan's response before I sent mine. In that
case: Ditto. :-)
- Jon
On Sep 25, 2006, at 12:49 PM, Alan Rother wrote:
Ideally you should use an online Credit Card Processor such as
Authorize.net,
in this case you do not need to store or send the CC details to
In every case I've done the research, using your non-web credit card
processing equipment for web transactions is a clear violation of their
transaction agreement.
Generally pointing this out to said client, and explaining his potential
loss of not being able to process cards for several weeks if
As the 'expert' in the process, the developer can be held partially
liable for allowing a scheme like this to go thru without being
clearly on record as advising the client, in the strongest written
terms, against this course of action.
If the client can't be talked out of this, write something
Thanks Matt,
My response is mixed in below...
*Assuming* you are shipping product immediately, or you are selling
something intangible like memberships that needs no shipping delay, then
you can settle immediately as well.Otherwise I'm pretty sure you are
bound ethically -- and probably
08, 2004 8:52 PM
To: CF-Talk
Subject: Re: Credit Cards - Best Practices
Lastly, you can opt to do it the safest way possible:Don't store the
cc numbers at all.Collect them on your secure form, send them to the
card processing gateway and DON'T store them.There are many who will
say
Neal,
*Assuming* you are shipping product immediately, or you are selling
something intangible like memberships that needs no shipping delay, then
you can settle immediately as well.Otherwise I'm pretty sure you are
bound ethically -- and probably legally in at least some areas -- to
auth at time
Lastly, you can opt to do it the safest way possible:Don't store the
cc numbers at all.Collect them on your secure form, send them to the
card processing gateway and DON'T store them.There are many who will
say this is the best way, and I think it is.It limits the customer's
liability and, perhaps
44 matches
Mail list logo
