 | Requirements for adding Pledge functionality to CiviContribute are being developed on this page. You can add your feedback as a "comment" - or add specific details to the requirements in the body of the document. These requirements are in "active discussion" as of May 2007. (Contributors to these requirements are listed below - add your name as applicable.) |
Requirements
- Track one-time pledges
- Track recurring pledges ($X each $period for $y duration or unlimited duration)
- Provide a way to relate incoming Contributions to Pledges (e.g. when a donation is entered for a contact, that donation can be related to an existing pledge)
- Reporting: upcoming pledges, unfulfilled pledges, etc.
- Handle the following cases:
- There is often a discrepancy between the amount pledged and the actual amount donated. Should be able to track the original pledge amount vs. the actual donation. This discrepancy is also decision support data for fund raising professionals.
- Pledges are often filled over the course of multiple donations. If I start with a pledge of $500 and then make a $50 contribution, we need to track that and allow reporting on it for decision support.
Details, one-time pledges
- date the person made the pledge
- amount pledged
- date when the actual money is expected (default to one month after pledge date)
- if money not received by that date, automatically create an "activity" to contact that person
Details, recurring (weekly/monthly/yearly/etc.) pledges
- date the person made the pledge
- amount pledged per period
- weekly, monthly or yearly
- until when
- total pledge value (amount per period * # of periods)
- track dates, amounts, of money received
- integrated with automatic recurring charging of credit cards
Details, all pledges
- total amount pledged but not yet received
- track whether a pledge was cancelled, and reason
- assign pledges to a particular "campaign" or "fund"
Optional features
- support for matching gifts
- display of progress toward a goal
End-User procedures (use cases)
Data entry tasks by office staff
- office staff logs a one-time pledge of a given amount
- office staff logs a recurring pledge of a given amount, plus receipt of first installment
- office staff logs a recurring pledge of a given amount, but no money received yet
Online pledging options (by supporters)
- supporter signs up for recurring pledge, pays first installment online by credit card, authorizes monthly charging of credit card
- supporter signs up for recurring pledge,promises to send first installment by check, selects "bill me" for subsequent installments.
- text values presented on the pledge page such as "bill me" are configurable to provide flexibility for various donation cultures.
c. supporters can sign up for various volunteer opportunities, or answer additional questions about interest areas, while pledging online (need a way to add custom-built forms/fields into the process for this).
Implementation Discussion
Data Model
Looks like a pledge is another top level object and could have one or more contributions associated with it which may or may not match the amounts on the pledge. The pledge object has a different set of attributes as compared to a contribution object (since its more high level and no gory details of a transaction).
We'll also need a recurring pledge object which holds one or more pledge objects which may be linked to a contribution object.
Given the above, i suspect we'll handle Pay Later for a contribution (or event) with just a status field (pending) and indicate its an offline payment rather than a pledge.
Pledge Properties
- date pledge made
- projected donation date
- reoccurring Y/N + details (monthly/yearly)
- active/canceled status
- contribution type
- (add more properties here...)
Issues
- Should we implement offline capabilities ONLY for Phase 1, and then add "self-service" online pledging later.
- If we move ahead with online pledge functionality, need to think about how pledges relate to existing Contribution page functionality (just another optional "block"?, separate form?...). Also need to deal with method for reconciling incoming online contributions against existing pledges.
- Reporting - could do this via the Contributions search interface (possibly a collapsible box with the pledge fields). Is this sufficient?
Contributors
The following folks have contributed to these requirements:
- Lucy P - Bay Area Nonviolent Communication
- David Geilhufe - CivicSpace
- Elin Waring
In the area of Events, we've been talking about the "pay by check" option, which would involve a registration and, essentially, a promise to pay. When the check is received, it is marked in the system as received. Is this similar enough to consider combining it with Pledges?
I've given this some thought the past few days, and i suspect not. I think in the case of a "pay-by-cheque/pay-at-the-door/pay-later" scenario, to a large extent the person has already committed and is paying for it at a later stage. So this is more like a magazine subscription or product where u r signed up but pay later
a pledge is more of a promise that the promiser could back off without any issues (IMO). Plus i think pledges will involve their own infrastructure that we might not want to tie into the "event" stuff
finally, not sure if an online recurring contribution is a pledge? to a large extent, you've already paid for it and the amount automatically is deducted etc. So is this a pledge? elin, any thoughts here?
Saying you will pay for some item (including an event ticket) in the future is not the same thing as a pledge. I don't think it counts as an asset in the same way.
To me, a recurring payment that that is not time limited is not really a pledge. The person can stop it at any time. It's a pledge if you said I will give $x over y payments. From my understanding, $x is accounted as donated in the same fiscal year as it is made, not the year that it is given. That is why a pledge is a serious commitment, moreso than if you say you will give so much a month indefinitely. If someone reneges on a pledge, an organization actually has to treat that as a lost asset in future accounting.
I am not an accountant by any means!! It may be that other types of non-profits account their pledges differently than churches. We solicit and record pledges in autumn, accounting them as assets in the fiscal year for which they are pledged.
In order to support these different models, so long as we can generate reports of pledge totals based on a range of "projected donation date" in order to know how much is pledged for "next year" then we're good!
As our income is 92% from pledges, I'll add my 2 cents...
An online recurring contribution shares all the important characteristics with a pledge - the only difference is the method of payment. It is a commitment to future income and it can be cancelled. Keep the model simple and make it a type of pledge.
Reporting should include pledge amount, amount contributed toward pledge and pledge remaining. We also include an "amount per period to complete pledge" in our interim reports to members. This helps them complete their pledge in even payments. For example, a member makes a $1,200 pledge for the year and makes a $100 payment in January and February. We send a statement after the 1st quarter that shows the $1,200 pledge, the two payments, the $1,000 pledge balance and a $111.11 monthly contribution, April-December to complete pledge.
Also, we collect and record 99.9% of our pledges before the fiscal year in which the pledges apply - In October for a Jan-Dec fiscal year. So for us, we would want beginning and ending dates for the pledge and total amount pledged for that period.
How will integration with the PayPal recurring payments work? Here is my use case:
1) member of organization visits my website and fills out a CiviContribute donation/pledge form.
2) Within the page they click a button labeled "Set up recurring payments now "
3) They fill out a form that gets sent to PayPal with all the hidden parms that PayPal accepts for setting up a recurring payment.
4) Pay Pal then initiates payment transactions per the payment schedule. The member does not make any other pledge donations from the website.
How would future PayPal transactions get linked/tied back to the original pledge amount?
Any processor that we eventually support recurring contributions for will need to have the capability of "notifying" CiviContribute as each subsequent payment is made. Currently, PayPal Web Standard with IPN is the only processor in the production codebase which supports this. Third-party developers are working on support for this w/ Moneris and Authorize.net - so hopefully these will be available in a future release.
What will happen using the current version of CiviContribute when an IPN for a recurring payment is received by CiviContribute?
Also, which release of CiviContribute will have the pledge enhancement?
The forums might be a better place to have this discussion. There is no target date for the pledge enhancement. If important to your org, please consider funding this functionality
Here's another idea.
From the above it seems that each org is going to want to deal with pledges differently. However the functionality needs to be basically the same as that for contributions. We just need a way of differentiating pledges from other contributions. So my suggestion is that we simply create a new payment processor called "Pledge". It would be fairly similar to the dummy processor, except it also provides support for recurring pledges. I think this would allow everyone to get their information segmented the way they need it, and without duplicating the entire contribution system.
This may require giving more power to payment processors. They would need to be able to:
-add fields to the edit/create payment processor screens (The pledge processor would ask if the admin wants to include pledges in totals, or to be totalled separately);
-have the option of being included in contribution totals, or totalled separately (The pledge processor would do whichever the user chose);
-be given opportunity to add links to the contributions tab (The pledge processor would add "Make a pledge" to the list)
-and asked which types of payments they can be used for (Pledges are only applicable to contributions, not to events)