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