NYCPHP Meetup

[Kristina Anderson]

Excellent points.  And I will pass the 'double transaction suppression' 
info on to my client so he can enable this.  With reard to storing 
credit card info on customers, I'd in general strongly advise any of my 
clients against going there -- with Paypal's (or whatever vendor they 
end up using) unique transaction ID that information is available in 
some form I'd imagine if requested...and also, that is what you are 
paying Paypal a percentage of the transaction for, so you don't have to 
trouble yourself about needing to store or request such information on 
your end of the app flow.

Interestingly, on this project I learned that there is a thing called 
Paypal Micro, where on transactions under a dollar they only charge 9 
or 10 cents per transaction, which is the only thing that makes it cost 
effective to sell such cheap products through Paypal, as ordinarily 
they'd swoop in and take a higher percentage of such a small sale.  To 
use it, any client has to set up a new Paypal merchant account separate 
from any non-Micro account they might already have, which is a pain, 
but worth it overall with the money saved.

In my app, the actual Paypal form is submitted by an 'invisible' PHP 
page that is never accessible to the user...so it's theoretically 
impossible for them to send it twice...I think.  In any event, this app 
is a single item click & pay thing so from an error handling 
perspective it didn't require as much as some more complicated Paypal 
stuff would.

This is the same method I'm incorporating to handle the error checking 
routine for the two form pages...passing things into hidden fields and 
submitting a second 'invisible' form with the values from the first 
form after the error conditions are satisfied.

I appreciate your coding style, Tedd, because I too am a huge fan of 
keeping it simple -- and also of 'brute force' methods that probably 
are not the most elegant of solutions but the important things (to me) 
are 1.  they work; and 2. when I go back to revisit code I wrote months 
or years ago, it's easier for me to understand what I was doing and 
reuse or enhance it.

-- Kristina

> -- Kristina
> 
> At 10:10 AM -0700 6/22/08, Kristina Anderson wrote:
> >Tedd -- this is very similar to the way you showed me how to use the
> >boolean 'step' value to exit the error checking loop if no error
> >conditions were found -- and just as simple to understand and 
brutally
> >effective...I love it!
> 
> I'm glad that you saw what I was doing. But, in all honesty I write 
> simple code because I look at problems that way -- I'm simple. The 
> complex I find too difficult to write so I pound on a problem until 
> it breaks into a series of simple parts that I can understand. Then I 
> just assemble the solution.
> 
> 
> >Im this scenario, if the user for whatever reason needed to reload 
the
> >page because of a malfunction, they'd need to establish a whole new
> >session and start over with everything...and presumably pay a second
> >time to be able to set up another account, which would dissuade them
> >very effectively. 
> >
> >In the Paypal app I recently built, I had them create an account 
and/or
> >log in using their unique email address before they were able to
> >purchase, and then captured their Paypal transaction ID (tx) upon
> >redirect, inserted it into a table along with the ID of the product
> >they had purchased, and authenticated against that for the download.
> 
> 
> What you have described is very similar to what I do. I know you know 
> how to do this, but for the benefit of any readers, I submit the 
> following to consider.
> 
> Before any purchase can be considered, the user must identify 
> his/herself via a logon, membership, or something that allows the 
> process to know this is a real person who wants to purchase something.
> 
> After that step, then comes the selection of product followed by the 
> payment process.
> 
> Once the flow is in the payment process, you don't want the user to 
> hit the back button NOR refresh their browser. So, I make a very 
> prominent warning (large red type) on that page that says if the user 
> clicks the back button or refreshes their browser, then that action 
> will cancel their transaction and they will have to start again. Some 
> actually read the warning and follow directions.
> 
> To accomplish this, I incorporate token checking (as I previously 
> described) to make sure they don't refresh the page as well as using 
> javascript to disable the submit button -- Ialso don't want users to 
> click the purchase button several times. It's really surprising how 
> impatient users can get (click, click, click.....).
> 
> But, regardless of what you do, you still have to plan that users 
> won't follow directions and that's the reason for the token.
> 
> Additionally, what happens IF the user has javascript turned off and 
> can click the purchase button more than once? In that case, I also 
> add another token routine for submitting data to PayPal. That way no 
> matter what happens (many clicks, refresh, back button), the request 
> for authorization is sent to PayPal only ONCE.
> 
> Oddly enough, that still isn't the end of it. You must also contact 
> PayPal (or whatever payment processing you are using) and ask them 
> for "double transaction suppression" to be turned ON at their end. 
> That way, it's almost certain that users won't be charged for the 
> same item more than once.
> 
> After all that, you should receive an authorization back from PayPal 
> that everything is OK. So, record that authorization and whatever 
> other user information you need and supply the user user with their 
> purchase. But note, it is very important that you drop ALL the credit 
> card information you have gathered in your script within 24 hours. 
> Keeping any specific cc information beyond 24 hours is against the 
> law.
> 
> As you well know, with a little work and understanding how the 
> process works, you can anticipate what user may do; gather the data 
> you need; and make the sale.
> 
> Cheers,
> 
> tedd
> 
> -- 
> -------
> http://sperling.com  http://ancientstones.com  http://earthstones.com
> _______________________________________________
> New York PHP Community Talk Mailing List
> http://lists.nyphp.org/mailman/listinfo/talk
> 
> NYPHPCon 2006 Presentations Online
> http://www.nyphpcon.com
> 
> Show Your Participation in New York PHP
> http://www.nyphp.org/show_participation.php