On Mon, Feb 28, 2011 at 5:02 PM, Ryan Schmidt
<[email protected]> wrote:
> I'm building a multi-page signup form, using the Wizard component, which
> seems to be pretty cool:
>
> https://github.com/jaredhoyt/cakephp-wizard
>
> After entering their preferred username, password, blood type, and mother's
> maiden shoe size, I'm going to be directing users over to PayPal to pay for
> these services they're signing up with me for. When the PayPal transaction is
> complete, PayPal will redirect the user back to a "done" page on my site. Or,
> if the transaction is cancelled in PayPal land, I believe PayPal will
> redirect the user to a "cancel" page on my site. On these pages I can then
> tell the user useful things, like "Thanks for giving me money" or "You didn't
> give me any money".
>
> Ultimately, I will want to use the data the customer has provided to create
> several database records: users, services, etc. I'm trying to determine what
> I should be doing with the user's data between the time they've entered it
> and the time they've succeeded in paying me.
>
> I could keep the data in the session only, until the "done" page is reached,
> at which point I actually save() it into the appropriate models. This is how
> the provided Wizard example handles it. One worry I have here is: what if the
> user picked a username, and I validated on page 1 of the wizard that it was
> unique, but by the time they came back from PayPal, someone else created that
> username. So the user paid me, but the save() into the database with all the
> data about what they paid me for fails. Maybe this is a rare enough occasion
> that I can get away with just logging all the data and manually fixing this
> later.
>
> I could create the e.g. User and Service records as soon as I have enough
> data from the customer. What if the user cancels the PayPal transaction? In
> the "cancel" page, I could delete the records again. What if the user just
> closes the window when they see the PayPal screen? My "cancel" page will
> never be reached and I'll have stale records lingering in the database. What
> if the user later comes back and tries again? Now the username they wanted to
> pick is already sitting around unused in my database and they can't have it
> anymore.
>
> To avoid stale or unfinished records in important tables like users and
> services, I could have an entirely new table, orders, and fill it with
> information about the order. After coming back from PayPal successfully, I
> could mark the order as ready to be filled. Then I'd need to transfer the
> data from the orders table into corresponding users and services records.
>
> Does anyone here have experience doing this kind of signup form and could
> share some recommendations? I'd love to hear what you did and whether it
> worked well.
I include certain data as PP's "pass-through" variables. This is done
by including hidden form elements with name "rvar_*" and whatever
value you care to have passed back. PP doesn't do anything at all with
the data, just passes it back along with the rest of its response. eg:
<input type="hidden" name="rvar_event_id" value="<?= $event_id ?>" />
I also created a dedicated model & controller as there were several
reasons why users might be sent off to PP. I included an rvar_request
pass-through value that tells what this payment was for and so, what
to do with the response from PP (ie. which tables to update on
succcess). First, the method grabs all the generic PP stuff and saves
to the transactions table.
$data = array('Transaction');
$data['Transaction']['order_no'] = $this->params['form']['order_no'];
...
Once the Transaction is saved there's a switch on
$this->params['form']['rvar_request'] and calls to setAction() for
further processing, such as updating the members or event_reservations
tables.
It definitely would be better not to have methods dealing with
specific things like "event" or "membership" (ie. something that could
be made a plugin) but I wasn't too concerned about portability in this
case. Perhaps a better approach would have been to call model-specific
methods to handle the tail end of the response.
--
Our newest site for the community: CakePHP Video Tutorials
http://tv.cakephp.org
Check out the new CakePHP Questions site http://ask.cakephp.org and help others
with their CakePHP related questions.
To unsubscribe from this group, send email to
[email protected] For more options, visit this group at
http://groups.google.com/group/cake-php
