"Stand Alone" Donation Page?

Hi All,

A non-profit client has asked me about using Zen Cart to implement a "stand-alone" donation page that would work like the donation pages served up by acceptiva.com. Here are some examples:

Kempe Foundation - https://secure.acceptiva.com/?cst=287515
Cancer Support Community - https://secure.acceptiva.com/?cst=980924
SBCC Foundation - https://secure.acceptiva.com/?cst=69e611
Penland School of Crafts - https://secure.acceptiva.com/?cst=37be0f

I've already successfully implemented a "donation product" that a customer can either add to the cart during the normal course of shopping, or at the end, during checkout, along the lines suggested in the following posts:

http://www.zen-cart.com/showthread.php?69958-Donation-like-product
http://www.zen-cart.com/showthread.php?122642-Adding-Donation-box-to-my-site

However, this doesn't satisfy the current client's fundamental requirements that:

1. A donor need neither have nor create an account to make the donation;
2. The donor's payment information must be entered on the same page as the specification of the donation amount and attributes;
3. There should be no way for the donor to get access to the cart (e.g., during the confirmation phase) in order to add other products from the store to it. In other words, the donation functionality should appear to stand alone, and not appear to be part of the client's Zen Cart store. The most the prospective donor should be able to do is adjust the donation amount/attributes and the payment information, or cancel out of the transaction altogether.
   I believe that requirement (a) above can be satisfied by the COWOA module (http://www.zen-cart.com/downloads.php?do=file&id=1115).

However, I haven't found any examples of Zen Cart stores that implement (b) or (c), nor references to add-on modules that might help in implementing such behavior. (If there are any such modules, I clearly haven't been creative enough to think of search terms that would shake them out of the forum! :unsure:)

So: does anyone have any pointers to add-on modules that might address these additional requirements, or, alternatively, on which templates I would have to customize to get the desired behavior?

Thanks,

M

You will have to create the form and method to capture the donation if this is required

But ezpages can accept most all html

admin > tools > ezpages

Okay, so if I understand correctly, the method that processes the form on the first ezpage would have to create and manage all the server-side resources that represent the transaction-in-progress, such as:

• create a shoppingCart object
• call its add_cart() method to put the donation product (with associated attributes) into the cart
• create/populate the order object
• create/populate whatever objects COWOA (or alternatively "Fast & Easy Checkout") uses to do its thing
• etc...
  Presumably I would also need a second ezpage (with its own associated form and method) for presenting the confirmation dialog and commit button, and for processing the payment; and then a final ezpage for displaying the "Thank you" coda. (Right?)

Assuming that this understanding is at least somewhat close to the mark, have you got any suggestions for me on how to structure the PHP module containing the method code so that it has access to all the needed server side assets, and also for where the resulting PHP module should live in the site's directory hierarchy?

Probably most helpful, if such a thing exists (and easier than writing a lengthy narrative), would be a pointer to an actual example of an ezpage containing a form for doing something non-trivial, and to the PHP module containing the associated method code.

Thanks,

M

If I understand the question, I have used Machform (not free, but worth the cost) to create stand-alone forms in EZ pages.

But ez-pages cannot handle PHP which you would need for creating opjects etc. You need to use define pages for that - they are PHP files themselves, whereas ez-pages are only database information.

Hmm... coding an HTML form into an ezpage doesn't seem to be where the major challenge of this exercise lies.

I'm much more concerned to know how to structure the back-end PHP code that processes the form -- which I don't think Machform will help me with, unless I've missed something in my quick perusal of the appnitro.com site.

M

gjh42:

But ez-pages cannot handle PHP which you would need for creating objects etc. You need to use define pages for that - they are PHP files themselves, whereas ez-pages are only database information.

Since I haven't played with ezpages at all, and have only done super-trivial things with define pages (certainly no form processing), I'm probably not really qualified to have an opinion on this, but: wouldn't it be possible to code the form on an ezpage, and implement the form-processing logic in a PHP module, which would be invoked via the form's "submit" method?

This was how I was interpreting Kobra's response to my original post.

M

create a shoppingCart object
call its add_cart() method to put the donation product (with associated attributes) into the cart
create/populate the order object
Why fuss with a shopping cart object??
Create the form as you posted where they can adjust the donation
You will have to hook to what ever payment processor you are using to process the payment
The Thank you can be just a html page with a link back to your shop

Processors usually have examples of html code to trigger collection

So no php code should be required

So no php code required

kobra:

Why fuss with a shopping cart object??

Well, I was hoping to capture the donation as a Zen Cart order, just as though it had come from a regular shopping interaction. Two main reasons for this:

1. I have to capture a number of items of information from the donor, including their name and contact information, employer information if their donation is to be matched by their employer, and honoree information if the donation is being made "in honor of" or "in memory of" someone else. Donor name and contact info would be captured by COWOA or Fast&Easy, and I was planning on representing the employer and honoree information as product attributes, which of course will only work if the donation is a product.
2. The donation amount needs to be reported to the Finance Dept., just like all other revenue inflows from the store. We already have a mechanism in place for batching store transactions over to the accounting systems, which is a wheel I'd rather not re-invent for this project.
   So, to process the donation as an order (assuming that I don't want to fiddle the store's MySQL tables directly :eek: -- which I really don't want to do), at the very least I would need an order object, populated with the correct product and customer information. It seemed that the most convenient way of getting one of those would be to start with the cart object.

kobra:

Create the form as you posted where they can adjust the donation
You will have to hook to what ever payment processor you are using to process the payment

And that's a third reason I think I need a PHP backend: the client's payment processor is Linkpoint. The only convenient access I have to that is via the store's linkpoint_api module, which offers a single PHP object ("lphp") whose curl_process() method takes an associative array of name/value pairs, does the XML interaction with the Linkpoint gateway, and hands back another associative array of name/value pairs.

kobra:

Processors usually have examples of html code to trigger collection

I'm struggling a bit to understand what you mean by this. Are you talking about HTML form code that would do an HTTP POST to a URL offered by the payment processor?

I guess that could be an easy option if the payment processor accepts URL-encoded post data, but as noted above, Linkpoint wants XML. The only way I can think of to create the needed XML on the client side would be to rewrite the code of the lphp object's buildXML() method in JavaScript -- which I wouldn't be at all keen on doing.

(Does Linkpoint have a non-XML gateway interface that I'm not aware of?)

M

There's a FAQ page on setting up a simple donation system. No programming required.

http://www.zen-cart.com/content.php?324-Variable-Price-Product-or-Donation

swguy:

There's a FAQ page on setting up a simple donation system. No programming required.

http://www.zen-cart.com/content.php?324-Variable-Price-Product-or-Donation

Been there, done that, got the T-shirt and the coffee mug. :smile:

Works well, as far as it goes, and I do hope to re-use it as part of the solution to the current requirement.

That said, please reread my original post, especially my client's list of "fundamental requirements" (labeled a., b. & c.), which are what I believe will require the programming.

M

I've got a turkey in the oven, so I'm abbreviating here ... but will fill in details tomorrow if you need.

To make sure that the shopping cart can't contain the donation product along with anything else, you'll need to create a script in the /extra_cart_actions directory. Essentially, you'll want to check the current shopping cart for the presence of a donation product and deny any additional products (with appropriate message). On the other hand, if the cart currently contains a donation product you want to deny the addition of any other product (with appropriate message). One of the shopping_cart.php class' member functions allows you to check for the presence of a specific product, to my remembrance.

I'd use the link that swguy proposed (the right direction, of course); the customer can edit his/her donation amount easily if you also install the "Edit cart" plugin.

lat9:

I've got a turkey in the oven, so I'm abbreviating here ... but will fill in details tomorrow if you need.

Happy Thanksgiving! I'm about to put my turkey (loaf :D) in the oven myself!

To make sure that the shopping cart can't contain the donation product along with anything else, ...

Thanks, but I have to stop you right there and ask you to do what I've already asked of swguy, namely: "please reread my original post, especially my client's list of fundamental requirements (labeled a., b. & c.)." And moreover, in this instance, the part of "c." that says "There should be no way for the donor to get access to the cart..."

The client isn't interested in any solution that exposes the cart to the donor (which, by the way, the existing checkout_confirmation page does, indirectly, via the "Edit" button in the "Shopping Cart Contents" section). In a solution that will actually satisfy the client, there should never be a circumstance under which the script you suggest putting in extra_cart_actions/ would run.

To be perfectly frank, the client doesn't even want the donor to be aware that they're dealing with an "online store" application at all, if possible. From the client's perspective, any mention of stores, shopping carts, "checking out", etc., will simply be confusing and frustrating to a person who has come to the site only to make a donation. (The reasons for wanting to nevertheless use the underlying mechanisms of Zen Cart, without exposing them to the user, are explained in this post.)

If you haven't tried one of the Acceptiva links in the original post, I'd encourage you to do so, to see how the client wants the interaction to flow. (Don't worry, clicking the "Proceed to Confirmation" button won't charge your card -- it takes you to a confirmation page where you can then abandon the transaction, if you wish.) No sign of a "shopping cart" in sight, and on the confirmation page, the only options offered are to either complete the transaction, or go back to the previous page and modify the information that's been entered.

I'd use the link that swguy proposed (the right direction, of course); the customer can edit his/her donation amount easily if you also install the "Edit cart" plugin.

Although the posts that I referenced in my original don't include the exact FAQ page that swguy cited, my intention was to point out that I have in fact already done precisely what he proposed -- hence my rejoinder of "Been there, done that..."

In fact, donation products implemented in that way are already in the client's store catalog, and the client has no problem with them as items that can be put in the shopping cart, even along with other products, in circumstances where the user is already shopping on the store site.

And, as I also mentioned in my response to swguy, I fully intend to use exactly the same kind of "donation product" implementation in addressing the client's current "stand alone donation page" request.

So... just to reiterate: what I'm looking for is an example of how & where to implement a PHP module that creates and processes an order (or does something similarly non-trivial with internal Zen Cart resources), in response to the submission of an HTML form that lives on an EZ-page (as suggested by Kobra), or a "define page" (as suggested by gjh42).

M

Sounds like all you need is a simple "Donate" button via your PayPal account. Just create an HTML page on your site, dump the button's HTML code into it, and you're done.
And if it's a registered charity, PayPal will grant reduced processing fees, making it all the more ideal for a complete solution to your needs.

DrByte:

Sounds like all you need is a simple "Donate" button via your PayPal account. Just create an HTML page on your site, dump the button's HTML code into it, and you're done.

I failed to mention: that's exactly their current "stand alone" donation solution, and they don't like it. That's why they're asking for something that looks more like the Acceptiva solution. (And are expressing some dismay that Zen Cart isn't easily capable of being configured to provide such a thing.)

M

hephaestus:

(And are expressing some dismay that Zen Cart isn't easily capable of being configured to provide such a thing.)
Of course they are.

Zen Cart is an ecommerce system, architected to have customers pick from a catalog, put things in their shopping cart, and proceed through checkout.
Your customers are specifically requesting something that does NONE of those three things.

So, any dismay they have is simply because someone hasn't sat down to rearchitect a new solution specific to their unique wishes.

You can rewrite the checkout any way you wish. Just be mindful that the current checkout flow is written like it is for many reasons ... some of them legacy, some of them driven by technical needs to work in a framework that can be used globally. You can of course rework any of it for your own bespoke needs.

That said, several approaches are already discussed here, and while your client has turned their nose at all of them, perhaps some could be a good starting point for inspiration while you write the custom solution tailored to their specific requirements.

And hopefully they'll let you release the solution's code back to the community so others can benefit ... just like thousands of others have done so you could have Zen Cart in the first place.