So, I made it to the last few minutes of the Churches and Ubercart BoF at Drupalcon DC and may not have the full picture on what was discussed. As such, I'm going to use this thread to just spec. out what I see as the desired solution for enabling church websites (and other non-profit organizations) to take donations online. It seemed like the folks in the BoF were willing to get behind a proposal, fund it, and start implementing it on their various sites. As such, I'd appreciate feedback on the items in this proposal, and assuming agreement from enough people, I'd like to open it up for contributions (most likely through ChipIn) and begin the development ASAP.
At the very least, there is a need for variable priced products in Ubercart. These should remove the qty. field from the add to cart form and make it instead an amount field. These products should also have their rows altered in the cart view form so users can update the amount they want to donate if necessary.
Furthermore, it sounded like most people wanted to send people straight to the checkout form when the amount form was submitted (and quite possibly empty the cart along the way). This involves changing the button text (as "Add to cart" is no longer applicable) and optionally emptying the cart of any existing contents. Ideally, the contents would be restored post-checkout, but for now lets just assume that it's ok to empty it wholesale and address the re-population issue in the future.
Finally, there was a request to support EFT for payment to cut down on costs associated with payment services and credit card transactions. There is possibly a solution for this already in contrib, but that will require some research. If not, I'd be keen to hear what solutions people are using already.
So... what needs to be coded?
- Product feature: Variable price. I'd go so far as to make the product feature settings form include...
- A title for the "amount" field
- A default value
- A minimum/maximum value
- An optional textfield to change the title of the "Add to cart" button
- Cart form modifications for products with the variable price feature
- Product feature: Add to cart tweaks. This one would cover...
- An option to empty the cart when this product is added
- An option to go straight to the checkout page
- Possibly: an EFT payment method with one or more payment gateways supported
I'd also like to consider some way to package this up so everyone out there doesn't have to duplicate the configuration. I'm happy to consider an installation profile based on UberDrupal that does the setup through a new "Donation" product class. However, the functionality should probably also be made available to existing sites, possibly in the form of a helper module that when installed gives you a simple settings form somewhere to have a one-click setup of the same "Donation" product class.
Development will all be done on Drupal 6. Back porting could be funded separately if necessary. For the first three top-level bullet points above, I'm going to give a rough estimate of $750, and that can totally be revised based on your feedback. Whaddya think?
Comments
Google Summer of Code 2009?
I know I'm starting to sound like a broken record, but...
Do you think this is significant enough to justify a student working on it all summer? Or, since it seems like the answer is probably "it's not enough" maybe it could be combined with some other Uber-improvements? I know I've needed this particular function multiple times--I just got a request a few days ago from a non-profit I am involved with--and I can probably think of a few more and it's not unheard of for a student to take on multiple improvements to an existing module (that's what ezra_g did for nodequeue last year).
At any rate- if you think it's enough work (or have some more ideas that could be added), would you mind cross-posting it/them on the soc group ( http://groups.drupal.org/soc-2009 )to see what the rest of the community thinks?
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Alex Urevick-Ackelsberg
ZivTech: Illuminating Technology
Hmm... hadn't thought of
Hmm... hadn't thought of that. Honestly, I can't imagine it taking even a total Ubernewbie more than a few days to figure out and implement. I do have a list of improvements to Ubercart that involve abstracting various systems in the core and contributed modules out into general API modules that might be better suited. Would it be cool if I e-mailed you the general list and some thoughts on these API module possibilities for feedback before posting elsewhere?
-
(Trimmed/moved for proper threading.)
existing module
I take it this has been tried and found wanting?:
http://www.ubercart.org/contrib/383
I'm currently implementing CiviCRM for donar a management, but I've dreamed of having a CRM solution that was better integrated with Drupal, and hoped Ubercart would be a big head start. I honestly surprised to hear that it doesn't already have this functionality.
Matt
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
That module you linked was
That module you linked was never even completed for Ubercart 1.0. There is a donations module available on drupal.org that was completed for 1.0 but never fully migrated to 2.0. The solution involves defining a new "donation" product type instead of functioning as a product feature. Again, I'm looking at Drupal 6 here and at using a couple smaller modules that can be pre-configured for users wanting to accept donations through any product on an Ubercart site. This will be more generically usable and is kind of a different model than the previous solutions.
I'd be willing to help in
I'd be willing to help in any way getting these implemented in ubercart. Even if its just documentation.
Freelancer
Twitter sdudenhofer
seth@osjournal.net
Memo Field
I know that at our church, there is a need to have a "memo" field - allowing the donor to specify which "fund" they would like their donation/offering to go to (i.e.: Building Fund, Fellowship Fund, etc.). It might easy enough to add a field just for a memo - much like you would have on a handwritten check.
As to avoiding duplicated installations, I believe there is talk of a Church install profile. This Uberdonation configuration would definitely be something that I would want to see included in that profile.
Thanks!
I should've mentioned...
I should've mentioned... making donations as products in Ubercart means you can use the attribute system to add a "Memo" or "Designation" textfield attribute to the donation. You can even add an option to the attribute and specify it as the default to populate the textfield with your default value. (I suppose you can always make that a select list, too.)
"I believe there is talk of a Church install profile. This Uberdonation configuration would definitely be something that I would want to see included in that profile."
Yeah, like an optional inclusion if you have the modules on the site. In UberDrupal what we're doing is completing the base install and then giving installers the opportunity to select one or more "packages" at the end to install and configure additional functionality. I'm doing my best to make sure that all the Ubercart setup happens through a .inc file that can be reused by other installation profiles.
Funding
I'm willing to round up funding for this, and i believe Brad Wade is as well. Can other church folks step up and offer a few dollars on this? I'm going to suggest Ryan starts a Chipin once the consensus is reached. :)
Ryan, EFT payment would be a KILLER add to this. Any idea on cost when it comes to getting the authorize.net module to link into their EFT system? I might suggest we wrap that into the project as well (even if it's technically a different module), since it's a very church-requested item. Can you give a total cost to accomplish that as well?
I'd also say that using a 'memo field' would be a good add as well.
I'd be happy to get people involved to get this paid for asap.
It looks like I can do the
It looks like I can do the EFT stuff through Authorize.Net in about the same amount of time if I do it as a single eCheck.Net module that defines the payment method. I'd just double the price then and should be able to do testing and development through my Authorize.Net development account. It would be great if this is included in the "Uberdonations" specification if I could get someone to volunteer to test the thing live before I tag it as an official release.
Ultimately, it should work where there is a generic EFT payment method module (not sure about the state of http://drupal.org/project/directdebit) with other payment gateway modules plugging into that. Given where we are in the Ubercart development lifecycle, though, I won't be able to get the code into core until later... so may as well make it a single eCheck.Net contrib.
Willing to donate funding, also
Just wanted to put in my two cents and say that I'd be willing to fund a project like this, too. Just let me know how we are doing it.
Count me in
As someone who makes a portion of his living creating websites for non-profits. I am willing to contribute funds to making this happen! I am also anxious to see the event registration functionality we discussed move forward as well. Thanks!
Willing to Donate...
I recently used Ubercart for a Church Camp registration site and loved the functionality that we ended up with. One feature I tried to implement with "Donations" was a "Scholarship Request" for a what you can afford amount. (In the end, we used attributes to offer different levels of scholarships).
That's not the point - I'm not trying to add to the feature request list.
The point is that I'm willing to give money to this project because of the helpfulness I received from Ubercart in general and would love to see it continue to move forward!
Clarified Functionality list and quote
I'd say the next step here is for Ryan to give us a clarified functionality list (or for us to add further requests for functionality) and then provide a final quote. Then setup a chipin and get this ball rolling.
Rob, I've updated the final
Rob, I've updated the final specifications wiki with what I believe are attainable first round goals. Assuming we can get this funded and developed over the next week or two, I've spoken to someone who is willing to fund the next step of packaging this up into an installation profile and making further features available through other modules.
Let me know how it sounds! I tried to be explicit about the scope of the features and where features have been requested that aren't slated for inclusion in the estimates. I'm totally up for future development if need be, but I think it's best to start with small, well-defined goals and work toward an "Uber-solution." I also tried to be fair in my estimates based on how long these sorts of modules have taken me in the past, esp. considering those unwelcome bugs that show up right when you're about to call it done.
Promote on ubercart.org??
Thanks Ryan. Wiki is looking good. Have you already posted this information on ubercart.org? If not, where in the ubercart forums would make a good place to promote this effort and find interested supporters?
I hadn't posted this, but
I hadn't posted this, but I'd say the announcements forum there would be a good place to drum up support.
Additional Functionality and Funding
Thanks so much, Ryan, for taking the initiative on this. I'll be able to round up some funding for this. (Thanks rob_feature for volunteering my money!)
I agree with rob_feature that we should bundle the EFT into this project, while keeping it a separate module. (I think it will be easier to raise funding for both items together.)
Other Features and Clarifications
*Setup recurring donations.
Donate $50 right now. Then monthly, on the 20th of the month, deduct that same amount from my checking account.
*Authorize.net
Integration should focus on Authorize.net as it is the most common (non-paypal) gateway.
*Designate Funds
A user needs to be able to designate funds to a specific ministry or make a donation "in memory of" someone. Select from a predefined list and enter "other" in a text field. All donations would have a default "General Funds" designation.
*Multiple designations through one checkout process.
This feature is a bit at odds with the very important "skipping the shopping cart" feature. Both could be achieved by having separate items/products for each designation showing on one screen, then adding multiple items to the "cart" at once. Or perhaps if this feature is desired leaving the shopping cart enabled so that users can return and select another item.
*Each Designation It's Own Page/Multiple Donation Products
I'm thinking that it may be a good idea for each designation to be its own product so that users can go straight to a page all about donating to that one thing. For example each missionary for the church could have their own product/page and the missionary could send potential donors directly to that page. Also if each are there own product, Admins could likely better take advantage of various reports created for products.
*Reports for Users
A user needs to be able to return to website and easily see donation history. (I don't think order history would be sufficient. We would need a report just showing the amounts donated sorted by date of donation. Or perhaps the report should be grouped by designation, sorted by date of donation.) Printable for Tax purposes.
*Admin Reports
Not sure what they would need.
-Brad
Example Use for Multiple Designations
Here is an example use case for Multiple Designations.
| textfield ($ amount) | label (designation) | [more info (link)] |
| textfield ($ amount) | label (designation) | [more info (link)] |
| auto-calc total | Donate (button) |
In regards to reporting for
In regards to reporting for tax purposes, is there need for allowing constituents to 'over-pay' for a physical product, and tracking fair-market value of the product for calculating the difference to include in the donation history report? Many organizations use this model.
Perhaps the 'minimum amount' field could be used for this purpose, or perhaps it needs to be a separate field.
My gut tells me this is too complicated for this first iteration, but I thought it was worth mentioning to keep in mind during development.
Also, it would be good to cross-reference the list of features for CiviContribute if this is going to be a viable alternative to CiviCRM:
http://civicrm.org/civicontribute
Best,
Matt
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
At this point, I'd like to
At this point, I'd like to stick with the idea that people can configure designations on their own using the attribute system. The only thing you mentioned that that does not support is the idea that choosing "Other" from a list allows you to specify in a textfield. Simple enough, though, you can just add a second optional textfield attribute to the donation product called "Other designation" so that people can specify if they want.
For multiple donations w/ varying designations, I'd just recommend not bypassing the cart and making sure people are aware that they can add more than one donation to the cart. Perhaps I can alter the specification for the "Add to cart tweaks" product feature to make the add to cart redirect optional... maybe even through a second add to cart button that adds the current donation to the cart and remains on the page to add another? Not sure what the wording on such a button would be...
I replied above about adding an EFT module to the specification, but I'm hesitant to make any confirmation regarding recurring donations. I think I'd want to make sure the base system worked before moving into recurring space, especially since the recurring fee module is one of the weakest from a user experience standpoint. It just never seems to quite fit what people expect it to do. : P Also, while I did see that I can specify an eCheck.Net payment as recurring, I don't see much documentation in the API docs about actually making it work. I think this will require work to be done on a larger scale to revise the core recurring fee handler and build eCheck functionality into Authorize.Net's CIM... a much larger task that is outlined here. : )
Good call on the reports. Those don't need to be anything fancy, right? Maybe just a list of donations for a specific calendar year? This could be built as a separate module or possible as a feature of the variable price module... I'm up for ideas. It shouldn't require much more effort depending on your specifications, so I'll estimate it around $250 - 500 more pending your feedback.
Great Example...
If you're interested in seeing a potential example of the whole process, Campus Crusade for Christ has a significant system in place: http://give.ccci.org.
As a former staff member who actually worked with CCC's web publishing, I can tell you that their system is very custom built - but that's not to say that it can't provide a vision/picture of what could be.
Every one of bradwade's feature suggestions are implemented in various ways. It's definitely worth checking out.
aaron
I was really impressed by
I was really impressed by their giving system when I signed up to support a friend serving w/ Campus for Christ Canada. : )
Wiki Added
This group post is a good place to throw around ideas and chat, but I felt we needed a more organized format for clarifying the current state of the spec. I created this wiki where we can solidify features and put some solid numbers to them.
Mostly, I'll ask that Ryan is the main editor of that document...he'll be the one that can most clearly see what he plans to do and how he'll quote it out. Please don't use that document to add feature requests, etc. If you plan on financially supporting development, it would be helpful if you went there and added your name to that list. Then, when we're ready to go, we can contact everyone.
So, Ryan, please edit that document as appropriate and we should get one step closer to a final spec on this project.
I'm not sure if it's
I'm not sure if it's possible, but could you move the wiki page from the Churches group to the Drupal Commerce one? Clearly this information will be of benefit beyond to just those creating sites for religious groups.
The Boise Drupal Guy!
Spread the word
It is my hope and goal that having churches initiate, support, and develop these modules for Drupal and Ubercart will benefit the entire community. It would be great if others would join us in supporting this development.
However, I'd rather leave the wiki where it is because we have already begun promoting it, tweeting the URL, etc. But I think you are right we should definitely go to other groups and let them know what we are doing and see if others have good ideas or want to support the effort. We should start some discussions in the other groups and link over to the wiki in the churches group.
What groups should we let know?
-Brad
What about uc_donation?
This sounds pretty much exactly like what I need, but I need to get moving right away... Is the http://drupal.org/project/uc_donation project close enough to get us there? It looks like there's activity on the project.
Indeed. As the author of
Indeed. As the author of Ubercart Auction, I know that Ubercart products with variable prices are not quite easy but relatively straightforward to implement. The new and possibly more difficult aspects of what Ryan has in mind seem to involve removing the shopping cart metaphor, allowing the donator to go straight to the checkout page without seeing a cart page first, etc.
Starting with UC Donation as a foundation of a "donation product" and then working on all the shopping cart-bypassing stuff from there might be a good strategy. The shopping cart-bypassing code could likely also be leveraged for smaller stores which are only selling one (non-donation) product, etc.
One of our clients recently asked for something like this, so I may be able to help as far as coding goes, if we get started fairly soon.
The Boise Drupal Guy!
My experience...
I have used the uc_donation module (http://drupal.org/project/uc_donation) on a Drupal 5.x/Ubercart installation. It works okay. Some minor issues that I was able to work around or ignore.
I have seen a lot of bugs in the Drupal 6.x version and heard others say they weren't able to get it working without it throwing errors. That said greenSkin just seemed to do some work on the issue tracker... so maybe now things are working better???
-Brad
[Edit: Just clarified exactly which module I was talking about.]
Donate to the Donate Module..?
How about a feature that would help get this module (and many others done)... Instead of a simple donate function, people could "Pledge" a donation amount toward a project/cause and only when a threshhold is met, would the trigger be pulled and everyone billed simultaneously. Using a church example, you could have a block showing .... "78% of funds raised to fix the old clock tower pledged."
For the specific issue of raising funds to start development of a module, I see that the wiki shows that there are a list of people "willing" to donate, but we don't know how much or when the new functionality would be started. Having people pledge would give visibility into how far along the donation process was, and might inspire people to pony up the last couple of bucks.
not a good idea
As people donate, the financial should be taken care of along the way. It's not nice to leave money in someone's account for an indefinite amount of time and then suddenly take it. If they aren't expecting it on a given day it could cause them trouble. Better to finish each pledge as a transaction at that time. Besides pledged money isn't reliable until it's actually transferred.
I'm assuming that I'd still
I'm assuming that I'd still be able to rig up PayPal as a potential donation option? Is that a safe assumption?
I'm interested in basic donation functionality. I'm not interested in providing donation history as this would not be complete unless it plugged into our donation tracking system and would give the donor false info. I expect the same would be true for churches. My primary concern is the ease of flow (usability) to the typical donor giving to a single project/fund. EFT/ACH/Echeck payment options are certainly a killer feature in my world.
I've heard talk of this being a setup where the fund would be placed on the memo line of a donation or something? Could I also easily setup the funds/projects as their own products so that I could provide a description of the fund and a "Donate" button on that product that would take them straight to the payment page?
My thoughts...
Hi all, I thought I'd come over and share my thoughts on the subject.
To start out with I love the idea of allowing products the ability to not set a price and leave it open for the user to choose as this will fit the needs of donation products and other such items. The only issue I see is that product features are enabled on a per product basis and would need to be implemented on every product needed, where this is adequate for sites that wish to only have one or a small number of these products, but it can become quite tedious for sites that use these types of products on a grander scale such as a donation product for each project an organization has it's hands in. With working with one such organization, the site user who has the ability to create these products likes simplicity as much as possible and with more steps comes more confusion.
I have not been following Ubercart as much lately as I have in the past so I have not kept up on the Drupal 6 version of Ubercart. Things might have changed more than I thought. I recall the ability to create a product class (I think was the term), basically an instance of the product content type, and if these are still in use I would like to suggest this product class can have the product feature applied to it and as a result each node of that content type applies the settings of that feature. Again, forgive me if this is already possible.
Thanks for bringing that up.
Thanks for bringing that up. That would be an issue in my case. I'd be setting up well over 50, maybe 100 of these from the start. It would be nice to not have to manually turn these on for each project we're involved in. It would be manageable and not worth a significant expense, but if it could be taken into consideration in the design, that would be nice.
Hey greenSkin, good call.
Hey greenSkin, good call. It isn't possible to auto-assign product features, but that could easily be done through hook_nodeapi(). It's a little late to make that a core feature of UC, but how about in the settings for the Variable Price product feature I put a checkboxes that will let you specify which product class should automatically get the feature?
i'm using donate on d6 and ubercart2 and uc_donation
I'm using donation product
Problem I'm having now is that Attributes does not work with Donate type, so doing this kind of thing doesn't work.
Donate $50 to pay for medicine for 1 family for a year
Donate $100 to pay for medicine for 2 families for a year
Donate other amount ________
So, either donation product needs tweaking to work with attributes, or product needs to allow attributes with an optional fill in box (which probably makes most sense, because then too i think ubercart marketplace will be more likely to work w donations without modification to marketplace [i think that is not working])
Also, someone mentioned people pledging to support this, rather than donating. I think that has some merit and in fact there's a site set up for exactly this kind of thing: http://www.thepoint.com/
I think it'll be far more motivating to know that $xxx is waiting for you if you complete the task, rather than having small donations come in dribs and drabs while you work on something while you can. I think this kind of model could really help drupal development move forward faster because then as a module developer you could say wow, i could take this job modifying a module and I know I'll get $x. You can then choose if you'll do that or dig up another consulting gig. Kind of an easy choice. But if you rely on donations coming in whenever they do, you still have to spend time digging up that next gig. i'd love to see thepoint integrated somehow w drupal modules so we can support easily like that.
Ryan Scott
Causecast.org
Ryan Scott
CEO, Causecast.org
We are hiring LA based drupal wizards!
First of all thank you to
First of all thank you to everyone helping Ryan create the specs for the new donation module and for everyone joining in at the DrupalConDC BOF.
I have posted up a ChipIn for this project on our own site as we can't post it here because of the input filter.
I believe about ten people have signed up to support this development which makes the $3000 spread out nicely.
http://www.commerceguys.com/about/news/commerce-guys-collecting-funding-...
So where is everybody? I put
So where is everybody? I put in the one tenth on behalf of Ninjitsu, at least for the portion we care about. EFT is not really in demand for us right now, so I'm ignoring that part. Perhaps we should remove that piece from the threshold to get things started? I think we're pretty darn close to the $2,250, so now is the time to act if you've been holding out.
Thanks,
Matt
Drupal.org user profile
Portfolio: http://www.NinjitsuWeb.com
Drupal Micro-blogging: http://twitter.com/matt2000
Drupal.org user profile
Drupal Micro-blogging: http://twitter.com/matt2000
Has this discussion moved?
Has this discussion moved?
I am attempting to setup a recurring donation system where a user can choose how often (week,biweekly,monthy) and how much. The latter option is more important.
I would be willing to front some programming time toward this development. Please contact me.
If anyone has any insight as to how to setup a donation with a user submitted amount that would flow into the uc_recurring or uc_cim i would greatly appreciate it. Even if this requires coding.
Right now im playing with setting up this combo of uc_cim, uc_donation, uc_recurring. I had setup a donation thinking it would transfer the user submitted amount to the uc_cim module but this was not the case. After digging through setting more. I saw this that following note that hinted me off that it was not possible.
--Recurring fee amount: $5.00
--Charge this amount each billing period.
--The product price is still charged at checkout.
On another side note.. does uc_recurring and uc_cim service the same purpose? or do they work hand in hand?
http://robisoncreative.com
http://lucasr.com
This should be
This should be possible/easier with one of the features I am wanting to implement in uc_recurring v2, which is an option to just make the recurring fee the same as the original purchase price (so it will inherit things like coupon discounts or in your case should be able to take the amount entered by the user via form provided by the donation module) - please see the issue queue at http://drupal.org/project/uc_recurring to add to the discussion on this feature.
Just a quick heads up to let
Just a quick heads up to let everyone know that we've received the bounty in full and appreciate everyone's support. I had the flu for a rough week and a half, so I'm polishing off a long overdue client site and will be hitting this work hard this week. I'll start posting modules as early as tomorrow and report in here as the work progresses. Thanks again!
Woohoo!
Just catching up on this. Glad to see it's coming to fruition!
Very cool
Just want to encourage this process along since we could really use it. My only suggestion would be to do some testing to make sure that this module will work with Quickbooks Integration (http://drupal.org/project/uc_qb) since being able to sync up the donation data with our accounting program would be critical. Granted that mod is unfinished, but I know people are using it and is a huge timesaver.
Also I would add a vote for recurring donations. Many charities have a form on their web site where you can fill in your bank acct info and dollar amount, and then they will make a monthly EFT. Our current bank seems clueless about this, and does not know how to set it up for us. Being able to do it in our drupal site would be awesome.
Thanks!
Alrighty, the UC Variable
Alrighty, the UC Variable Price module has been posted and packaged up as a release candidate. I'm looking for feedback on the module to make sure it was developed in accordance with the specifications and to make sure the features all work as necessary.
The only known issue is that for some reason or another, a special JS behavior I added to enable "override" checkboxes to display their associated textfields with JS doesn't work on the product class forms... it works fine on the individual feature forms on each product, though. Weird. If that doesn't make sense, it's just eye candy and nothing that will affect the functionality of the module. ; )
Please post bugs in the issue tracker for the module. Feature requests can be posted, but I'll most likely be militant about keeping things in scope for now... I'm not even including one of my own in the 1.0 release. : P
And now the UC Add to Cart
And now the UC Add to Cart Tweaks module has been posted and packaged up as a release candidate. Again, feedback on the module would be much appreciated. I believe it captures the specifications, and it was simple enough to accomplish using the Variable Price module as a template.
Please post bugs in the issue tracker for the module. Again, feature requests can be posted, but they will most likely be postponed until the other development is accomplished. Patches are always accepted. ; )
Last one for the day... I've
Last one for the day... I've added the UC Ordered Products Reports module to get some early feedback on the code. It's released as a beta version, because I have not yet added support for CSV exports on the administrator report. As soon as that's done, I'll package it up as a release candidate.
I may be a little more lenient on feature requests for this one that have to do with fields available to the report or titles for the user profile tab. Check it out now and let me know if you have any feedback. Also, if anyone can review this for access control issues and report filtering/sorting issues I'd appreciate it. I already know about and have fixed in CVS the fact that the admin permission wasn't required to tweak the basic report settings. D'oh.
Please post bugs in the issue tracker for the module.
Quick heads up that this
Quick heads up that this module has been moved into release candidate with some bug fixes and CSV export support. Review away!
And now for the final
And now for the final module, behold UC eCheck.Net. This one is still in beta, because I found that I couldn't automatically enable eCheck.Net support in my Authorize.Net developer account. I'm waiting to get that approved, so I'm curious to know if anyone who might have an Authorize.Net account with eCheck.Net can test this in the meantime.
There are a couple of issues in the tracker to take care of, but then it should be good to go. I'm interested in feedback on the ordering and description of fields on the checkout form for the bank account information. As always, bug reports should go to this module's issue tracker. I look forward to wrapping these up and seeing them in action!
And now this module has been
And now this module has been completed with some changes to the API and messages and the addition of an admin terminal form for processing eCheck.Net payments for customers as an administrator. Have at it! I've tested this with my developer test account but would love more eyes on the code and UI.
Status of this module
Hi All,
I'm interested in this module as a replacement to using CiviCRM contribute module which is all I use CiviCRM for... This sounds like a perfect solution. Does it work similar? Is it ready for prime time?
I'm gonna try it out when I get a chance.
C.
I believe so
I'm using uc_varprice to enable donations on one site so far, and it seems to be working great.
Noobie confusion
I guess I am not getting this. I have the ubercart modules installed, including the ones mentioned in this thread. I configured a donation "store" and a donation "product" and enabled variable pricing on it. But it still looks like a store where you can buy a product, not a page seeking donations. It displays a SKU, a shopping cart containing products with a quantity field, etc. How do you make it look less like a ... store? Or am I missing the point?
fixed/variable donation amounts
I need to create a donation product with multiple fixed donation amounts in addition to a variable (i.e. "other") amount.
This would entail a list of radio buttons with the following corresponding amounts:
$5
$10
$25
$50
$100
$250
$500
Other $______
UC Variable Price modules sounds perfectly suited for the "other" amount, but what about the fixed amounts? Can a single donation product have multiple price levels (fixed and variable)?
Also, what's the difference between the UC Variable Price and Ubercart Donation Products modules? The former was created by Ryan (which adds creditability for obvious reasons), but the latter has been around longer and has greater download activity (according to the usage statistics). Most importantly, which is most appropriate for my intended purpose?
All comments/suggestions appreciated.
If I recall correctly (it's
If I recall correctly (it's been a while since I've used it), UC VarPrice does indeed have that functionality.
The Boise Drupal Guy!
indeedly!
UC Variable Price does indeed support predefined (i.e. radio buttons) amounts with this patch.
Kudos to both Ryan and Garrett Albright for producing this excellent add-in module.
Oh yeah. I remembered that
Oh yeah. I remembered that this feature existed, but forgot that I was the one who built it. :P
The Boise Drupal Guy!
Donation Module wish list
Hi All,
Back in September, I launched a non-profit website that takes donations. My client required the following,
I wanted to use Ubercart because I had used it once before and I thought it was pretty good but I couldn't see how to use it for the parameters above.
Fortunately CiviCRM's Contribute module did all of the above. Unfortunately, CiviCRM is not that easy to set up and maintain. What behemoth! Sorry Civi lovers but I'm not a huge fan except the contribute module.... its installation is bigger then the whole of Drupal! and the the number of database tables enormous. I'm dreading having to update the software - If Ubercart has a viable option by then I may just switch over.
I would really recommend that you look at CiviCRM's Contribute module as a guide of features because its really all there. It even
has a pledging module where individuals can pledge an amount and it keeps tabs on incremental payments. (I'm not using this feature and a 'Badge' option to include in your email so others can help you reach your donation goal)
Hope this helps!
C.
spoke too soon
Unfortunately I am experiencing the same problem as described in this thread, where the page fails validation when adding the product to cart. I am willing to apply the proposed patch in the thread, but I have already applied the aforementioned radio button patch so there's bound to be a conflict. Any advice?
Final Release
Hi There,
Read through the entire thread as well as the wiki page - some very cool modules. I'm looking for something to be able to set up donations on a not-for-profit site and these seem to fit the bill nicely. Only question I have is regarding the final production release. The modules have been at the RC3 stage for a while now (since May 09 it appears). Does anyone have any idea when they will be promoted to a 1.0 release?
Cheers,
Kris
Don't know
But I've used the most up to date ubercart modules in a couple of production sites, and they have worked really well.
Fundraising feature request
Hey guys please take a look at the wiki I have just added: http://groups.drupal.org/node/171029
I have outlined some proposed features I believe lots of people will benefit from. Would love some feedback!
Craig Bertrand