Question regarding auto monthly transactions.

Hello All,

We are discussing the possibility of allowing members to sign up to pay their memberships (and perhaps other donors/donations) through automatic, monthly withdrawals. Ideally, these monthly withdrawals would be recurring each year until the members tells us to stop. We are looking for the best options to make this a smooth system for Accounting.

I don’t think we’re necessarily interested in setting up “pledges”. If someone wants to give us $35 (or any amount) a month, we want it to run in perpetuity until they tell us “stop”. 

I don't think Pledge Billing utility is what they're looking for. Or is it?

Payment Plans? 

Is anyone doing something like this? 

Thanks,

Nathaniel 

  • I don't think there's a way to do this without using pledges and the Pledge Billing Utility.  This is what we use for our monthly donors and it has to be re-setup every fiscal year for proper reporting for Accounting and the Development team.

  • That’s it exactly, Kyle. It really is best to create the pledges.
     
    Each fiscal season, I create a new year of pledges for our 100-ish monthly donors and once a month the Pledge Billing Utility is run to automatically process those gifts. It takes a couple of days to set it up but that’s a small amount of pain for the time it saves in having the report do all the work.
     
    Michael Joyal
    Direct 204 954 6411
     
  • You might want to consider Donate2 - https://www.donate2.com/  It integrates with Tessitura.  The High Museum in Charlotte uses it for auto renew memberships.  It's very flexible and removes all the follow up time for development staff when credit cards are about to expire or card is declining on pledge payments.  

  • I previously created a semi-automated way to facilitate perpetual regular contributions using a combination of TNEW's contribution page and the Contribution Import Utility. In general, the process was:

    • The TNEW contribution page provided a form to capture a patron's contribution preferences. This included amount, contribution frequency, etc. This first contribution would then be processed as a normal contribution upon completion of the transaction.
    • The contribution preferences captured in the mentioned form would then be saved to a local system table instead of a CSI. A daily database job would then be run to check the data in this system table to determine whether are there any regular contributions that need to be processed on the day based on the contribution frequency that was captured from the patron.
    • If yes, the job would execute the Contribution Import Utility and create the required contributions in a Controlled Batch ready for processing. A notification e-mail would then be sent to Philanthropy / Development staff notifying them that there are pending contributions waiting to be processed. Staff would then simply need to review and close the Controlled Batch which will then trigger the authorisation of the patron's credit card for the required contribution amount. Any issues with a transaction like expired cards, etc. would also be flagged here.
    • The process did require the initial set up of a Contribution Import Set and ensuring that the relevant Campaign, Fund and Source Numbers were correct but that ended up being an annual update depending on how the Contribution Campaigns were set up. The contribution preferences stored in the local system table also allowed staff to amend or disable any record in the event a patron wanted to stop their regular contribution. It also allowed staff to manually add any new non-TNEW regular contributions if required.

    This was a very customised process but got the job done enabling perpetual regular contributions and required minimal maintenance. It also negated the need to have an end date for a regular contribution processed as a pledge. Hopefully this helps spark some ideas along with all the other useful comments and feedback that have already been mentioned. Thanks!