Credit Card & PCI compliance.

[Tom Running]

I have questions which regarding PCI compliance.

0.
Would someone able to shed some light on how the credit card logic work?

1.
Does it contact the credit card authorize gateway for a small authorize
amount  and
void if success.  Then captured the final CC amount at the order picking
and shipping manifest process?

2.
Does it keep or store the customer Credit Card information on the OFBIZ
server?
Credit card information such as:
PAN, expiration, CVV...


3.
If it stored credit card information on the server, does it encrypted
before written to
the database?

4.
If it store the CC information on the server but doesn't encrypted.
Does anyone has done this before?

Thank you.
Tom

[Mauricio Tavares]

On Mon, Oct 6, 2014 at 11:52 PM, Tom Running <[hidden email]> wrote:
> I have questions which regarding PCI compliance.
>
      Rule 0: PCI compliance is designed by banks to protect banks
while keeping government regulations away. As far as the merchant is
concerned, it is like riding a motorcycle: when bad things happen, no
matter who is wrong you always lose.

> 0.
> Would someone able to shed some light on how the credit card logic work?
>
      Which part?

> 1.
> Does it contact the credit card authorize gateway for a small authorize
> amount  and
> void if success.  Then captured the final CC amount at the order picking
> and shipping manifest process?
>
      Besides costing you a transaction, making a small payment ($1)
is deprecated. If the sale is right now (buying cat food at the
store), you can just make the sale. If customer does not have money,
sale is denied and reason is given by processor. But, you can always
do a hold. If customer has no money, hold will fail. If there is
money, hold is created. When sale actually takes place (say online
site and you are about to ship), convert hold into sale. Unused holds
expire within a week.

Now, there seems to be a gas company that will not convert the hold
into a sale even after sale is made or cancelled. I do not think that
follows the rules.

Use a return instead of a void since a return removes hold immediately
while void won't. Customer will prefer return. Refund is a different,
post-settle, bag of cats.

> 2.
> Does it keep or store the customer Credit Card information on the OFBIZ
> server?
> Credit card information such as:
> PAN, expiration, CVV...
>
      AFAIK, it shouldn't, but I may be wrong. The software I worked
with would be put between, say, OFBiz and payment processors. It can
keep customer credit card info, but since it is PCI compliant by
itself -- if you lose the admin password or the db key (need both to
access DB), you are better off settling remaining transactions and
starting over -- the merchant exposure is reduced. So all OFBiz has to
do is send payment info and do something based on reply; it should not
need to keep PCI data.

>
> 3.
> If it stored credit card information on the server, does it encrypted
> before written to the database?
>
      If it does, it better. Once again, I can't see the reason why it
would. When you use something like the software the place I worked at
sells, paypal, google wallet, paymentech, and the other usual portal
suspects, they store the card data in their servers. Ok, our software
would store in *your* server because we are not a portal, but it likes
to keep its database encrypted in a paranoid way (we have no backdoor
if you loose your admin pw). In fact, when "experts" were talking
earlier this year about the important of 2048 bit encrypted, my boss
laughed and said "er, we have offered 2048 bit encryption for more
than 10 years now."

Which leads to: the connections between each device/program that makes
the chain going from credit card to payment processor better be
encrypted.

> 4.
> If it store the CC information on the server but doesn't encrypted.
> Does anyone has done this before?
>
> Thank you.
> Tom

[Ted Byers]

For several years now, I have been working in the area of developing
software to support ecommerce; specifically in the area of supporting
electronic transactions, and risk management.

On Tue, Oct 7, 2014 at 7:59 AM, Mauricio Tavares <[hidden email]>
wrote:

> On Mon, Oct 6, 2014 at 11:52 PM, Tom Running <[hidden email]>
> wrote:
> > I have questions which regarding PCI compliance.
> >
>       Rule 0: PCI compliance is designed by banks to protect banks
> while keeping government regulations away. As far as the merchant is
> concerned, it is like riding a motorcycle: when bad things happen, no
> matter who is wrong you always lose.
>


That may be, but some processing banks will not give an account to a
merchant that is not PCI compliant.  Note, this usually means a security
audit, including penetration testing, on a regular basis; among other
things.

>
> > 0.
> > Would someone able to shed some light on how the credit card logic work?
> >
>       Which part?
>
> > 1.
> > Does it contact the credit card authorize gateway for a small authorize
> > amount  and
> > void if success.  Then captured the final CC amount at the order picking
> > and shipping manifest process?
> >
>

No, that is a dumb way to do things.  Authorize for the full amount, and
use a fraud detection service.Submit the authorization to the bank, and
asyncronously submit the requisite data to the fraud prevention service.
If the fraud service detects a potential issue, then void any successful
authorization (no need for action if the authorization fails),  You will
have results from both within 5 to 6 seconds.  If the intent is a regular
sale, then proceed with a capture if the fraud service does not detect a
problem and the authorization succeeds.  If either fails, then return the
appropriate error message to the end user.  In fact, some gateways have no
authorization service, but rather implement their sales in precisely this
way, except that they process the automatic capture days afterward rather
than immediately (I do not see the sense of such a delay, but that is the
way some do it).  But, if the intent is just a sale, and you do not want to
use a fraud detection service, then just process the sale as you were
advised.

>       Besides costing you a transaction, making a small payment ($1)
> is deprecated. If the sale is right now (buying cat food at the
> store), you can just make the sale. If customer does not have money,
> sale is denied and reason is given by processor. But, you can always
> do a hold. If customer has no money, hold will fail. If there is
> money, hold is created. When sale actually takes place (say online
> site and you are about to ship), convert hold into sale. Unused holds
> expire within a week.
>
> Now, there seems to be a gas company that will not convert the hold
> into a sale even after sale is made or cancelled. I do not think that
> follows the rules.
>
> Use a return instead of a void since a return removes hold immediately
> while void won't. Customer will prefer return. Refund is a different,
> post-settle, bag of cats.
>
> > 2.
> > Does it keep or store the customer Credit Card information on the OFBIZ
> > server?
> > Credit card information such as:
> > PAN, expiration, CVV...
> >
>       AFAIK, it shouldn't, but I may be wrong. The software I worked
> with would be put between, say, OFBiz and payment processors. It can
> keep customer credit card info, but since it is PCI compliant by
> itself -- if you lose the admin password or the db key (need both to
> access DB), you are better off settling remaining transactions and
> starting over -- the merchant exposure is reduced. So all OFBiz has to
> do is send payment info and do something based on reply; it should not
> need to keep PCI data.
>
>

A PCI compliant merchant is not allowed to store credit card information
unless they use a PCI compliant vault (probably what the software you
worked with did, but there is more to it that just software - a properly
designed vault requires a whole separate subnet, and a whole series of
security protocols to ensure only authorized machines can talk to it).

> >
> > 3.
> > If it stored credit card information on the server, does it encrypted
> > before written to the database?
> >
>       If it does, it better. Once again, I can't see the reason why it
> would. When you use something like the software the place I worked at
> sells, paypal, google wallet, paymentech, and the other usual portal
> suspects, they store the card data in their servers. Ok, our software
> would store in *your* server because we are not a portal, but it likes
> to keep its database encrypted in a paranoid way (we have no backdoor
> if you loose your admin pw). In fact, when "experts" were talking
> earlier this year about the important of 2048 bit encrypted, my boss
> laughed and said "er, we have offered 2048 bit encryption for more
> than 10 years now."
>
> Which leads to: the connections between each device/program that makes
> the chain going from credit card to payment processor better be
> encrypted.
>
>

Yes, if you must store such data, ensure it is encrypted, but be careful of
the algorithm used, and make sure you fully investigate how to create,
manage and use a vault so that such sensitive data is stored ONLY in a
properly designed and implemented vault.  For most merchants I have seen,
it is more cost effective to buy vault services than it is to try to make
your own.  As an aside, I would not be pleased with your software storing
such data on my server, and had I been involved in it, I would have
insisted on using the processing bank's services designed for that
purpose.  If the processing bank does not provide such services, then I'd
either find a different one or I'd find a gateway that deals with it and
that does provide such services.  The liability involved means that in most
cases, it is not worth the cost of doing it yourself.


> > 4.
> > If it store the CC information on the server but doesn't encrypted.
> > Does anyone has done this before?
> >
> > Thank you.
> > Tom
>

Only a raving lunatic would even consider storing such sensitive data in
clear text.  Do not do it!  If you do, you open yourself up to a whole new
level of pain and risk.  In all the time I have been working in this
industry, I have never even considered storing such sensitive data on my
servers.  The only use case where it makes some sense is in the realm of
recurring billing (e.g. monthly subscriptions to services), and for that it
is infinitely better to rely on the processing bank's vault and API for the
recurring billing rather than building your own.

Cheers

Ted

--
R.E.(Ted) Byers, Ph.D.,Ed.D.

[Tom Running]

Thank you for all the comments and ideas.
Is there a document that would address and confirm my concern and questions
regarding the
local credit card storage?

1.
I have a need to store credit card # on local server to accommodate some
business requirements.
This will enable ONE CLICK order using the existing credit card on file.
Similar to what Amazon shopping cart offered.

Another option I am thinking of is offering customer ability to store and
select different credit card at the check out.

Perhaps, there are a better way to achieve the above requirements without
store the credit card i# locally.  Any suggestion?


2.
Would Ofbiz enable the credit card to process multiple (concurrent)
transaction at the same time?
Tradition, credit card systems often only allowed to process one
transaction at a time.
And if a locked happened or something similar occurred  than the whole
credit card incapable of processing any subsequent
transaction.

Thanks,
Tom



On Tue, Oct 7, 2014 at 8:43 AM, Ted Byers <[hidden email]> wrote:

> For several years now, I have been working in the area of developing
> software to support ecommerce; specifically in the area of supporting
> electronic transactions, and risk management.
>
> On Tue, Oct 7, 2014 at 7:59 AM, Mauricio Tavares <[hidden email]>
> wrote:
>
> > On Mon, Oct 6, 2014 at 11:52 PM, Tom Running <[hidden email]>
> > wrote:
> > > I have questions which regarding PCI compliance.
> > >
> >       Rule 0: PCI compliance is designed by banks to protect banks
> > while keeping government regulations away. As far as the merchant is
> > concerned, it is like riding a motorcycle: when bad things happen, no
> > matter who is wrong you always lose.
> >
>
>
> That may be, but some processing banks will not give an account to a
> merchant that is not PCI compliant.  Note, this usually means a security
> audit, including penetration testing, on a regular basis; among other
> things.
>
>
> >
> > > 0.
> > > Would someone able to shed some light on how the credit card logic
> work?
> > >
> >       Which part?
> >
> > > 1.
> > > Does it contact the credit card authorize gateway for a small authorize
> > > amount  and
> > > void if success.  Then captured the final CC amount at the order
> picking
> > > and shipping manifest process?
> > >
> >
> No, that is a dumb way to do things.  Authorize for the full amount, and
> use a fraud detection service.Submit the authorization to the bank, and
> asyncronously submit the requisite data to the fraud prevention service.
> If the fraud service detects a potential issue, then void any successful
> authorization (no need for action if the authorization fails),  You will
> have results from both within 5 to 6 seconds.  If the intent is a regular
> sale, then proceed with a capture if the fraud service does not detect a
> problem and the authorization succeeds.  If either fails, then return the
> appropriate error message to the end user.  In fact, some gateways have no
> authorization service, but rather implement their sales in precisely this
> way, except that they process the automatic capture days afterward rather
> than immediately (I do not see the sense of such a delay, but that is the
> way some do it).  But, if the intent is just a sale, and you do not want to
> use a fraud detection service, then just process the sale as you were
> advised.
>
>
> >       Besides costing you a transaction, making a small payment ($1)
> > is deprecated. If the sale is right now (buying cat food at the
> > store), you can just make the sale. If customer does not have money,
> > sale is denied and reason is given by processor. But, you can always
> > do a hold. If customer has no money, hold will fail. If there is
> > money, hold is created. When sale actually takes place (say online
> > site and you are about to ship), convert hold into sale. Unused holds
> > expire within a week.
> >
> > Now, there seems to be a gas company that will not convert the hold
> > into a sale even after sale is made or cancelled. I do not think that
> > follows the rules.
> >
> > Use a return instead of a void since a return removes hold immediately
> > while void won't. Customer will prefer return. Refund is a different,
> > post-settle, bag of cats.
> >
> > > 2.
> > > Does it keep or store the customer Credit Card information on the OFBIZ
> > > server?
> > > Credit card information such as:
> > > PAN, expiration, CVV...
> > >
> >       AFAIK, it shouldn't, but I may be wrong. The software I worked
> > with would be put between, say, OFBiz and payment processors. It can
> > keep customer credit card info, but since it is PCI compliant by
> > itself -- if you lose the admin password or the db key (need both to
> > access DB), you are better off settling remaining transactions and
> > starting over -- the merchant exposure is reduced. So all OFBiz has to
> > do is send payment info and do something based on reply; it should not
> > need to keep PCI data.
> >
> >
> A PCI compliant merchant is not allowed to store credit card information
> unless they use a PCI compliant vault (probably what the software you
> worked with did, but there is more to it that just software - a properly
> designed vault requires a whole separate subnet, and a whole series of
> security protocols to ensure only authorized machines can talk to it).
>
>
> > >
> > > 3.
> > > If it stored credit card information on the server, does it encrypted
> > > before written to the database?
> > >
> >       If it does, it better. Once again, I can't see the reason why it
> > would. When you use something like the software the place I worked at
> > sells, paypal, google wallet, paymentech, and the other usual portal
> > suspects, they store the card data in their servers. Ok, our software
> > would store in *your* server because we are not a portal, but it likes
> > to keep its database encrypted in a paranoid way (we have no backdoor
> > if you loose your admin pw). In fact, when "experts" were talking
> > earlier this year about the important of 2048 bit encrypted, my boss
> > laughed and said "er, we have offered 2048 bit encryption for more
> > than 10 years now."
> >
> > Which leads to: the connections between each device/program that makes
> > the chain going from credit card to payment processor better be
> > encrypted.
> >
> >
> Yes, if you must store such data, ensure it is encrypted, but be careful of
> the algorithm used, and make sure you fully investigate how to create,
> manage and use a vault so that such sensitive data is stored ONLY in a
> properly designed and implemented vault.  For most merchants I have seen,
> it is more cost effective to buy vault services than it is to try to make
> your own.  As an aside, I would not be pleased with your software storing
> such data on my server, and had I been involved in it, I would have
> insisted on using the processing bank's services designed for that
> purpose.  If the processing bank does not provide such services, then I'd
> either find a different one or I'd find a gateway that deals with it and
> that does provide such services.  The liability involved means that in most
> cases, it is not worth the cost of doing it yourself.
>
>
> > > 4.
> > > If it store the CC information on the server but doesn't encrypted.
> > > Does anyone has done this before?
> > >
> > > Thank you.
> > > Tom
> >
>
> Only a raving lunatic would even consider storing such sensitive data in
> clear text.  Do not do it!  If you do, you open yourself up to a whole new
> level of pain and risk.  In all the time I have been working in this
> industry, I have never even considered storing such sensitive data on my
> servers.  The only use case where it makes some sense is in the realm of
> recurring billing (e.g. monthly subscriptions to services), and for that it
> is infinitely better to rely on the processing bank's vault and API for the
> recurring billing rather than building your own.
>
> Cheers
>
> Ted
>
> --
> R.E.(Ted) Byers, Ph.D.,Ed.D.
>

[Scott.]

Tom,

You should check with your provider/gateway on what solutions they have for recurring billing. If you store credit card data in your DB you're going to have to go through a much higher level of PCI compliance. AFAIK, this includes annual on site audits, etc. regardless of volume.

Many providers now have api's that allow them and not you to store the actual CC numbers but still allow for recurring transactions. You should check there first.