Recurring Contribution Process
The CorePro API supports the concept of recurring contributions. A recurring contribution is defined by the various recurringContribution
properties on a customer's account
object.
The Recurring Contributions Process does not create any transactions itself. It simply notifies you which accounts (and amounts) customers have configured to automatically deposit money into CorePro on the following day.
Process Overview
- CorePro generates a Bulk Transfer Initiate File
- The following day, you begin the Bulk Transfer Process based on the above file.
No transactions are created until the Bulk Transfer Process is started.
Workflow
- Every day, the CorePro Recurring Contribution process will determine which accounts have contributions scheduled to happen on the following day.
An Initiate File is generated by CorePro and uploaded to
sftp.corepro.io
. This file will contain all basic information needed for you to create a Request File for upload the following day.NOTE: No further action is performed in CorePro at this point without receiving a subsequent Request File.
i.e. no transaction is ever created in CorePro as part of the Initiate File generation process and it will not appear in the customer's transaction list. A transaction is created only when the Request File is received and processed by CorePro. - Your system downloads the Initiate File from
sftp.corepro.io
and processes it.Your processing should involve investigating the Initiate File and processing it accordingly. Some examples include:
- Create transactions in your system to denote the actual transaction which will take place the following day (assuming you upload the Request File)
- Contact customers via email or SMS to notify them their recurring contribution will happen the next day, giving them a chance to cancel it
- Simply log the data for future use
- Follow the Bulk Transfer Process to actually transfer funds.
Simplified Workflow
The simplified workflow has the following prerequisites:- You do not need to give your customers the opportunity to cancel or void a recurring contribution the day prior to it occurring
- i.e. All Content rows that are in the Initiate File will always appear in the corresponding Request File
- Your code does not need to populate the
TransferTag
field with a specific value when performing transfers via the Request File- i.e. Nowhere does any of your code depend upon the
tag
property of thetransaction
object being populated
- i.e. Nowhere does any of your code depend upon the
- Download the Initiate File. Suppose its name is
201401152209_BULKTRANSFERINITIATE.TXT
- The next day, rename that file to
20140116_BulkTransfer.txt
and follow the Bulk Transfer Process.
NOTE: If you look at the files carefully, you'll notice the TransferDescription
field in the Initiate File matches up exactly with the TransferTag
field in the Request File.
Code exists to specifically ignore the value of Recurring Deposit
if it occurs in the TransferTag
when processing the Request File in order to support this Simplified Workflow.