Skip to content
This repository has been archived by the owner on Mar 27, 2022. It is now read-only.

Roadmap: Giving

Justin Lane edited this page Sep 22, 2015 · 23 revisions

We're dialoguing about the best way to incorporate giving functionality into OneBody, and this page records those discussions. Comments, ideas and contributions welcome.


Basic Requirements

  • A member should be able to make an online donation
  • A member should be able to review their donations
  • An administrator should be able to record donations of cash and cheque(s)
  • An administrator should be able to view and reconcile payments.

How might a giving/tithing process work?

There are two actors in the process: a) a member, who makes the donation b) an administrator, who reconciles the online payment

Member makes a donation

  1. Member signs in to OneBody
  2. Member navigates to make a donation
  3. OneBody retrieves merchant detail and tithe number to link payments to account
  4. User chooses amount and frequency(?)
  5. OneBody sends request to payment processor with the following details:
  • Card Type
  • Card Number
  • Expiration Month
  • Expiration Year
  • CVV details
  • Name on Card
  • Any reference fields that might be required
  1. Payment Processor Receives Request - Approves or Declines
  2. Payment Processor sends result back to OneBody

Administrator reconciles the Online Payment

This process reconciles payments received from the payment processor to OneBody, and optionally, to the church bank account. Process normally occurs on the next business day, as most payment provider cutoffs are late in the evening (10/11pm)

A potential flow might be:

  1. Create a row in a request table when a request is initiated by the user (step 2)
  2. Hit that table with the result from the payment processor
  3. Each day, an adminstrator (or automated process) retrieves a reconciliation file with details for the previous day
  4. The reconciliation file is loaded to OneBody
  5. A process is run to "auto-match" transactions
  6. Errors get resolved

Payment Processors

We need to support different payment methods in different countries. Probably the best way to do this is to recommend that a church signs up with a payment provider.

We know OneBody has been downloaded for use in the following countries (languages):

  • United States
  • Spanish
  • Portugal
  • Romania
  • Netherlands

Some of the more common payment providers for these countries are:

Processor Fee
simpledonation.com $44 per month
paypal.com 3.4% + 45c per transaction
stripe.com 2.9% + 30c per transaction
eway.co.uk(nz) $15 per month + 10c per transaction

We might need to support a couple of providers to get good coverage. Maybe just one initally to see if it takes off.

Once you start getting into Online Payments, you need to be aware of PCI-DSS compliance (the rules for securing credit cards for payments). This article explains it well. From this article, I think we'd be looking at a SAQ-A certification of sorts.

Since I'm looking at Stripe, I'm planning on purchasing and reviewing the book Mastering Modern Payments before going too much further down this road. We could also look at ActiveMerchant as this seems to be industry standard.

Reporting The following reports have been identified:

  • Transaction Listing

User Security

  • We'd need a new "Finance Administrator" role to process the cheque, cash and other payments, and perform any reconciliation work.
  • For Custom Reports, I'm envisaging a new category (Finance). You'd have to have the Finance Reporter and Manage Reports permissions to be able to create a financial report.

Wireframes


Some (very incomplete) wireframes to help flesh out the detail. I've shared them in the slack #ideas channel if they don't show up here.

Setup

Setup

Batch Entry

Batch Entry

Other

Outside of the reconciliation process per se, the following functions have been identified:

  • Refunding - Using the administration page, you can also initiate a refund. (Process: To be Documented.)

  • Giving Certificates - Create a tax-authority approved "certificate" (printed record of donations) for each giving period (eg quarterly/yearly). OneBody should also keep a copy of the data that was used to create the certificate.

  • The solution needs to support mobile devices (can do currently through responsive design)

  • OneBody's host needs to support SSL to accept online payments.

  • Different churches have different approaches and emphases on giving.

To be discussed

  • Refunding - Should we support that? Is there a need for it?
  • Recurring payments (how are these handled through payment providers - Should we support them?)
  • Guest access to make a donation?
  • Pledge(s)
  • Would we support cash donations into the Giving Certificates (ie would we use OneBody to hold all giving for an individual (or would we just process the online piece ?) - perhaps in later phases?