Author Topic: Looking for input on what to do with ACH/EFT returns (Read 513 times)

KarinG · September 12, 2014, 08:01:48 pm

I'm looking for some input/ideas on how to best handle ACH/EFT Returns.

For ACH/EFT - an example timeline looks like this:

Sep 05 - person registers online: purchases an event ticket -> contribution status = pending
Sep 06 - ACH/EFT gets a OK:BankAccept -> we fetch this with a scheduled job -> and contribution status = completed IF OK:BankAccept (if Reject -> Rejected)
Sep 12 - Return: REJ 61- NSF (not enough money in the account to cover the ACH/EFT) -> this we can also fetch with a scheduled job [we can check in every day and find today's Returns] -> and we can change the contribution status from completed to e.g. = cancelled (in CiviCRM you can not change status back to pending once completed).

A. right now administrators get an Email from iATS saying: an ACH has been returned
B. they can then go in and: do something with the contribution (change status or add a second - negative - one)
C. in case of a Membership or Event - more work would be needed
D. but what exactly that more work is will vary by organization. Will they want to change the status of the corresponding Event registration? Or will they keep it as completed - and Email the person saying please bring cash to the door? Or perhaps an organization will decide to delete the Event registration all together - and I'm sure there are many other workflows possible

Question is what do we need to do (if anything) on the payment processor side of things?

Automation:
1. We can find the returns from the CSV from iATS
2. We can set the contribution status to cancelled (or keep the original one as completed and add the Return itself for the equal but opposite amount; and while at it - set the non-deductible amount of the original - still completed contribution to its full amount - so that it doesn't accidentally get Receipted for Income Tax purposes; this more closely resembles an actual return - it's two line items in the iATS journal)

And then what next?
Just doing 1 and 2 is a bit dangerous - it's only a partially automated workflow. Is 1 and 2 still useful if admin still has to do the next steps re: Event and / or Membership registration?

-- Karin

SarahG (FountainTribe) · September 14, 2014, 04:27:13 pm

Karin -

What do you mean by "1. We can find the returns from the CSV from iATS " Could you elaborate?

My thoughts: Automation is essential. Many nonprofits are very short-staffed and there is no reason to consume staff time (and add the possibility of mistakes) for something that can and should be automated.

My idea:
Sep 05 - person registers online: purchases an event ticket -> contribution status = pending (same as your forum post)

Sep 06 - ACH/EFT gets a OK:BankAccept -> we fetch this with a scheduled job -> and contribution status = "in progress" IF OK:BankAccept (if Reject -> Rejected)

Sep 12 - Return: REJ 61- NSF (not enough money in the account to cover the ACH/EFT, or donor's bank does not allow ACH, or any other rejection) -> change the contribution status from "in progress" to "failed"

Sept. 13 or 14 -( ie a date that is past the point of no return, pun intended) or iATS provides a confirmation of transaction success(I would prefer iATS to provide this confirmation info, seems risky to rely on an assumption of well it has not been returned yet, so it must be completed)
On this date (or better yet on success confirmation from IATS), change the contribution status to "Completed"

Whatever happens this has to play nicely with the CiviCRM accounting batch workflow that nonprofits use to export the financial data to their general ledger.

So for ACH transactions that eventually succeed, the contribution lifecycle will be:
"pending" --> "in progress" --> "completed"

For ACH transactions that do NOT go through ( for any reason: invalid bank account number, NSF rejection, any other issue that prevents success)

"pending" --> "in-progress" --> "failed"

or

"pending" --> "failed"

(This lifecycle should hold true for a one-time contribution as well as recurring contributions. ( ie the 6th installment in a recurring contribution should be treated the same as the 1st installment)

KarinG · September 14, 2014, 05:04:34 pm

ad 1. - we can fetch a report from iATS - that will show us data (CSV) -> which contributions have been Returned. In iATSPayments.com -> these data are stored behind the ACHEFT Return button - we can fetch this via the WebServices API.

So an:
ACHEFT is submitted to iATS
then after processing (takes a few days) it goes either in the ACHEFT Approval or the ACHEFT Reject
let's say the +$100 contribution is approved - the ACH verifiy job in the iATSExtension pulls the ACEFT Approval and the ACHEFT Reject reports -> and toggles status to Completed or Rejected.

then it can happen that an ACHEFT a week or so later ends up in the ACHEFT Return (according to iATS this can happen for weeks after the initial OK:BankAccept)
-$100 contribution (this is actually a NEW transaction)

So there is no date that is past the point of return - there is no confirmation from iATS of monies-are-indeed-transfered-success. iATS returns the ACHEFT Approval - and in most cases that means things will go through - but at times the monies are subsequently Returned.

So we can't go:
"pending" --> "in progress" --> "completed"
Unless staff will be toggling to completed upon viewing the monies in the organization's bank account. It's far too dangerous to make assumptions like: hasn't appeared in ACH Return for one week - so probably has gone through. What if this was an Event registration - and a person needs tickets (which wouldn't be available for in progress - but would be for completed)

"pending" --> "completed" --> and then "cancelled" when a RETURN report is automate-able. I can fetch that data. I can grab what is behind that ACH Return button and automate that.

What I'm mostly wondering is what to do with Event and Membership attached to Contributions that are Returned. That logic to me appears to be very different amongst organizations.

SarahG (FountainTribe) · September 15, 2014, 08:22:50 am

Karin - Perhaps we should schedule a GoogleHangout or skype call to discuss this.

It sounds like what I previously proposed (ie don't change status to complete until successful transaction confirmation from iATS) is not realistic, since iATS does not provide that confirmation.

My revised thought - when a "REJ" message comes back, create a new contribution record for the opposite amount: if the original amount was $100, the new contribution amount would be $ -100. You would have to be careful to preserve the original line item amounts, financial types, etc. This, in theory, should play nicely with Financial Accounting batches exported to the general ledger. ( ie what if the bookkeeper has already exported a batch with the completed ACH transaction, then that transaction was later rejected. ) Just curious how bank reconciliation of deposits would work. How would the bookkeeper know the 2 contributions are related?

For events: Check into the new feature in CiviCRM version 4.5 that allows for partial payments ( ie multiple transactions) for a single event contribution. In 4.5, there is a calculated balance for that event participant. This will allow the bookkeeper to know that the event balance is $100 expected in the case of a partial payment, or a transaction with a negative amount. (hopefully the same feature for 4.5 events can be expanded to cover memberships too. ) What is key is for the bookkeeper to have a way to know that there is an open balance for a particular thing.

CiviCRM Community Forums (archive)

News:

Author Topic: Looking for input on what to do with ACH/EFT returns (Read 513 times)

KarinG

Looking for input on what to do with ACH/EFT returns

SarahG (FountainTribe)

Re: Looking for input on what to do with ACH/EFT returns

KarinG

Re: Looking for input on what to do with ACH/EFT returns

SarahG (FountainTribe)

Re: Looking for input on what to do with ACH/EFT returns