[pmwiki-devel] database tools and hacks in PmWiki

[Crisses]

On Dec 10, 2006, at 1:13 PM, marc wrote:

> Crisses said...
>
>> I have thought through the product/service end of the shopping cart,
>> but not the order storage end.  Storing credit card/bank information
>> in flat files is absolutely out of the question for me
>
> This isn't necessary. All the payment gateways I've used don't require
> it and it's better to steer clear of the legal issues. Repeat payment
> mechanisms are almost always available too. Even if you wanted to
> collect CC info to pass through on a secure connection, there's no  
> need
> to store it.

If you've ever programmed an API for a payment system, you're ahead  
of me.

I was only READING the documentation for the QuickBooks payment  
gateway the other day, and YES, one would be dealing directly with  
the payer's credit card info on the PHP/pre-API end.  We're talking  
100% must have SSL, etc.  Must store info, except the handy-dandy  
code on the back of the card that we shouldn't even be requesting the  
user to enter, and absolutely MUST NOT store.

>> one reason I
>> love PayPal from a liability/programming point of view -- absolutely
>> no need to store financial information on the system.
>
> Well, I loath PayPal - and enjoy a steady stream of work moving folk
> away from them :-) - but collecting payment info prior to  
> commencing the
> payment transaction is not a requirement with any of the payment
> gateways I've used.

If you have the experience, again, you are far far ahead of me.  For  
me, it's all theory.  I'm reading up on things.  If your payment  
processors are storing customer's info so you can request returns or  
issue credits, etc. then it's better than what I've seen & read so far.

If you have experience with shopping carts and payment processors,  
could you please give comments and contributions to the ideas for the  
shopping cart for PmWiki, or write one?  I am struggling with the  
amount of complexity behind it.  If you have dealt with the payment  
processor APIs and would like to see a shopping cart system in  
PmWiki, can you help?

>> The moment the
>> shopping cart system requires working with other merchant processing
>> systems that require the shopping cart to handle sensitive financial
>> information, we're entering very mucky territory in the way PmWiki
>> handles data.  You must store the customer's credit card in case of a
>> product return, or needing to issue a credit, etc.
>
> This isn't how it works, in my experience. The payment gateway  
> provides
> an interface that allows you to access the transaction and either  
> refund
> or make a part repayment. At no point do you need the credit card
> information.

That's not what I've seen.  I would welcome a list of payment  
gateways, but note that some customers come with an API/system they  
want to use because it's tied in with their in-store terminal  
already, or their bank, or some other deal they've already signed on  
to....

The rest I do encourage to use PayPal, at $0 up-front costs, and most  
of my customers are probably under $1000/month sales.

>> But you can't store it in a text file.
>
> Why not? Technically, I mean, since I don't this either.

Technically? Of course you can.  Why not?  Because most people are on  
shared hosted servers.  That means they can get the www process to  
peek at your file system, maybe.  Possibly.

>> Do we use GPG?  That doesn't work, because the web server would need
>> access to the keys.  It's a pain, and so far a database is the best
>> answer I have.
>
> You could store the key outside the web space and include the file.

See about shared hosting situations.  I don't trust flat file storage  
on multiuser systems.

Heck, nowadays you can't trust your hosting system's employees not to  
steal customer info and sell it -- even banks and financial  
institutions can't trust their employees.  In a court if someone said  
"How did you protect your customers' information" I want to be able  
to honestly say I used all reasonable means.  Flat files are not all  
reasonable means.  I have yet to have a hosting situation where I  
can't get access to a MySQL database if I want or need one.  It's not  
the most secure thing ever, but it's one of the reasonable and  
securer means.  The safest is to abstain entirely from storing any  
damming information.

Thanks,

Crisses