Fundraising system spec
Jump to navigation
Jump to search
Specification
Just some thoughts to start off:
- Banners - click through passing a banner ID
- Don't need to worry about this, this is handled by CentralNotice.
- Except do worry about the "clickthrough passing ID" bit - CentralNotice will pass a campaign/banner ID, we also need to assign an ID to each landing page, and the resulting string (BannerID + LandingpageID) needs to be committed to the donations that we end up with in CiviCRM.
- Landing page - collect the ID of the banner that referred them
- This contains a form but we want to collect as little info here as possible: If they pick PayPal for example, then PayPal collects the info.
- We need to collect whether they will do Gift Aid
- Question: is this for internal records, or just to tell the payment gateway? (I assume the former)
- The former. Specifically, if they select the Gift Aid option (which must be an opt-in option with the correct text) then this information needs to populate a given field in CiviCRM when the transaction is complete (ideally, it would only populate this field IF the donor has provided a sufficient name and address BUT if this proves difficult we can assume that we will get this information from the payment processor) and (preferably) the Gift Aid status should be acknowledged in the thankyou page and acknowledgement email. The payment gateway doesn't know or care about Gift Aid.
- Question: is this for internal records, or just to tell the payment gateway? (I assume the former)
- We need to collect data protection opt-in information (tickbox) and this also needs to be committed to CiviCRM
- Cf our landing pages last year, which worked well. We need to make sure that these landing pages are highly configurable - last year they were set up on a MediaWiki wiki which gave a high level of control to non-techie fundraisers, we need that again.
- Once details are supplied on the landing page, we send them to a donation form. The donation form is pre-populated with those details the donor has already selected on the landing page, i.e. their chosen donation amount and method.
- PayPal
Credit cardCredit card payments are taken via Paypal.- Set up a Direct Debit
- Post a cheque to the Office (?) This information needs to be present on the form somewhere, but doesn't need a high profile.
- It may be that it's better to collect data protection / gift aid information on the form rather than the landing page. This is something we'd need the ability to configure/test
- PayPal has an API
- Paypal has a number of APIs :) which one are we using?
- SmartDebit is used at present for processing card payments
- Direct Debit has an API (yes it does [1] - but you have to email SmartDebit for details)
- Yes, it does.
- Donor database
- Specifically CiviCRM. What we need to happen is that the data the donor provides on the form is committed to CiviCRM automatically once the payment processor has confirmed that the transaction is valid, and not before.
- From a technical perspective; just needs a table with all the donor data + transaction ID which can then be pushed to CiviCRM when the payment gateway API confirms the payment. Varies by gateway but all let you set a custom ID to transactions.
- It would also be helpful to get the name and address fields rendered into the proper case, so that we have clean data - sending letters/emails addressed to mr joe bloggs or MR JOE BLOGGS isn't great.
- From a technical perspective; just needs a table with all the donor data + transaction ID which can then be pushed to CiviCRM when the payment gateway API confirms the payment. Varies by gateway but all let you set a custom ID to transactions.
- Specifically CiviCRM. What we need to happen is that the data the donor provides on the form is committed to CiviCRM automatically once the payment processor has confirmed that the transaction is valid, and not before.
- Email integration
- Specifically (at minimum) sending a Thankyou email when a donation is confirmed (or via a batch process within a few hours). The text of the thankyou email needs to be configurable if necessary. Ideally the thankyou email will confirm the sum and (for DDs) frequency of the donation, and also confirm the Gift Aid and data protection information supplied.
- The thankyou page should be a configurable page (e.g. a wiki page). We should also offer donors the chance to sign up for additional information from Wikimedia UK.
Timescales
The fundraiser will run most probably through November, December, and January. We'll need a functioning, tested system rather sooner so that we can be certain we can go into action from Day 1 of the fundraiser without hitches. It will be necessary for the software developer to be available at reasonable notice during the period to solve unexpected problems or to tweak the functionality if circumstances dictate.