NYCPHP Meetup

[tedd]

-- 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