CiviCRM Community Forums (archive)

We are currently using CiviContribute with Authorize.net's ARB subscription API to process regular monthly donations to both our non-profit ministry staff and to specific ministries. We had created a set of Custom Fields for each staff member so that when a donor completed the contribution form they could select which Staff member or Ministry to give to each month using the ARB. We need to see this both for our own reports, and for the email receipt we send to donors.

This worked well for the first payment in the subscription. The Civi form submitted all the transaction data to Authorize.net, created the payment and subscription, and sent a confirmation back to Civi via the Silent Post. Civi received it, confirmed, and sent out a confirmation e-mail to the donor with the transaction and Custom Field information. This included the name of the Staff or Ministry they had signed-up to give to each month. Great.

Now that the next month of the ARB rolls around, the process changes slightly and we see a kink in our plan. Authorize.net is now the initiator of the next transaction in the subscription. They run the next ARB payment, and send a confirmation to Civi via Silent Post. Civi receives it, confirms it, but now has no Custom Field data for the next transaction. The email confirmation that is sent to the donor this time does not have any data for the Staff or Ministry they are giving to. This is creating confusion for the donors, as well as the end reports.

So, we can see the problem, but do not know what to do next for a solution. Help please?

Maybe we are going about this all wrong then. We have custom fields attached to the contribution. As you said though, the contacts may have more than one designation.

Our goal was to allow specific Staff and Ministries to receive recurring donations to their accounts. Their donors would select them online and setup the ARB. Then we would run a report to pull down who received what, and disburse funds accordingly.

We could not see another way to handle this with Contribute as it collects all funds with any inherent designations. Any ideas how we could accomplish this? 

Okay ... still thinking this all through, so let me ask another question.

How does Civi tie together Recurring Contributions? Is it the Civi Invoice ID? (i.e. "fd8c345190ff612fdbb02f6a50ead3e1").

I am just trying to think of how we could either go back programmatically and check the Custom Fields from the first payment in the series, and pull that out into reporting etc. Or, even better yet, the possibility of storing custom field values like Staff designations directly within the Invoice entity, or whatever the correct entity is.

Just trying to figure out how to get us where we need to be on this ...

Anyone else out there implement a designated donation type of solution like this?

Bingo - that's what I needed 

Now we just need to dig into learning how to modify the core a bit to suit our need for Staff and Ministry designations. Ideally, we could create a custom table "Designations" and then store the "DesignationID" FK in "civicrm_contribution_recur" table. Update the interface and forms a bit to suit end users selecting the designation accounts and the Find Contributions interface, reports etc.

Thanks ...

We hit problems because of this model - we want to use the custom data in aggregate reports & wind up using a script to copy it into the other contributions/ or to create pledges to track them. I like the idea of the custom data being attached to the recur - but that still wouldn't allow aggregate reporting with recur & non-recur contributions together

Right - All that attaching custom data to the recurring entity would do is simplify including that data on the email reminders, but it does not give us what we really need is transparency for specific designations on all contributions - both recur and single. Not sure how to get there yet ... 

Because the subsequent ARB requests coming from Authorize.net are essentially posting new payments each time, it no longer retains the previous custom field post data, and so the later payments contain no custom data. And yet Civi knows that these payments are part of the same set of Recurring Contributions. Looking at the database tables it appears that the 'Processor_ID' in the 'civicrm_contributions_recur' table is the same matching value as the Authorize.net "Subscription ID" - this is the ID that they use to collect the set of payments together into the same ARB subscription. I am assuming then that here is a check in Civi when it receives a new transaction from the Authorize silent post if the payment has a matching 'Subscription ID" to its "Processor_id" and if so updates the status of payments. So, we need to come up with a hook or something to catch these when they come in and update the new payments with the original Custom Field data. Kind of hacked, but seems like it should work.

Have you done something like this, and how did you go about it?