spike: sub-package for common ACH workflows

[GrahamMcBain]

What were you trying to do?
There are many common use cases for ACH that all require the same logic. This sub-package would create methods that handle these use cases and enable people to more quickly get up and running with the project.

As a project we strive to have no opinions and focus on creating the very specific technical spec. There is some fear that this is a more opinionated offering that wouldn't fit with the goals of the moov OSS project.

What are some workflows you would like to see supported if we were to take on this project?

[warrendub]

As a developer embedding Moov into my application for ACH transfers, I want to simulate initiating transfers and seeing them change status (e.g., from pending to processed; from pending to failed) while I am still operating in Sandbox (i.e., not yet moving real money). This is important to me because I am building out workflows in my app that are triggered on the change in status notification and I want to make sure it is working before we migrate to production. Ideas on how to help me:

1. Create "Sentinel Values" that only activate in the Sandbox environment (i.e., are disabled in Production) so that when an ACH transfer is Posted in Sandbox with an amount of, say, $197197.19 - it triggers a workflow that causes the Transfer record to initiate in status pending and then X seconds later change status to processed (triggering the appropriate webhook events / notifications). Similarly, a transfer with amount $198198.18 would trigger a pending to failed workflow.

[warrendub]

As a developer building Moov ACH transfers into my application, I want to confirm that a processed ACH transfer actually arrived into the destination bank account (because a variety of actions in my app get triggered when funds have actually arrived). I could build the logic to parse transactions myself inside my app, but then every developer of every app is building effectively the same logic and none of them have a clear unique identifier to match the received transaction back to the initiated transfer. Waaaay cooler would be if Moov: i) inserted a unique transfer identifier into the submitted ACH transaction that reliably showed up in the description field on the transactions; ii) automatically triggered the Plaid/Yodlee integrations Get Transactions to bring back transactions on the receiving or sending account (whichever I have authorization to access); iii) built a transaction parser that looked for the unique ID in the transaction descriptions and confirmed based on amount and date that the transaction actually did show up in the receiving/sending bank account; iv) triggered an automatic status update on the transfer record to a new status "settled", which triggers a webhook event or notification. Now, as a developer using Moov I can post my ACHs, get authorization from my user to access the bank account via Plaid etc and just wait for Moov magic to confirm that funds have been received/sent. (Note as crazy as this sounds - it is doable - we built it at my last bank, just not open sourced)

[warrendub]

As a developer building Moov ACH transfers into my application, if an ACH transfer gets returned for any reason (1-120 days after the transfer settles) I need to match that return transaction back up to the initial transfer record to know which customer's balance I need to adjust (if using an omnibus FBO account) or which transfer record details I need to pull to support disputing the return. This can be really complicated because the data that I get back in the ACH Return transaction especially when filtered through my partner bank's core system or through Plaid/etc, isn't very helpful. This is a harder one to solve for because of the variability in core systems and aggregation APIs - but, super cool if the same workflow used to match settled transactions could be modified to look for transactions of Type = ACH Return and if a successful match could result in a change in transfer status from "settled" to "returned" with appropriate notifications.

[adamdecaf]

These test harnesses sound great - thanks for writing them up! I think we want to develop a larger test setup that'll hook into PayGate and the FTP server so it can test these specific cases. We'll need to use tools outside of just ACH file generation (this project) to complete these tests.