Fundraising system spec

From Wikimedia UK
Jump to navigation Jump to search

Specification[edit | edit source]

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.
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.
  1. PayPal
  2. Credit card Credit card payments are taken via Paypal.
  3. Set up a Direct Debit
  4. Post a cheque to the Office (?) This information needs to be present on the form somewhere, but doesn't need a high profile.
  5. 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.
  • 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.
  • CiviCRM integration
    • CiviCRM has an API...
  • Thank you page
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[edit | edit source]

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.