On Mon, Oct 6, 2014 at 11:52 PM, Tom Running <[email protected]> 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
