payin via ACH debit

[chadwhitacre]

was: take money from Carl's bank account

@carljm thought since he connected a bank account that we would take his money.

Want to back this issue? Post a bounty on it! We accept bounties via Bountysource.

[chadwhitacre]

+1 from @bjeavons on Twitter.

[zbynekwinkler]

If this issue is about being able to charge the bank account instead of the credit card, count me in. Balanced is taking only 1% fee instead of 2.9%.
+1

[seanlinsley]

@whit537 the name of this ticket is very... interesting. Wouldn't it be more accurate if it was something like "Allow for withdrawals from bank accounts"?

[chadwhitacre]

@zwn And ACH debits are capped at $5, so for larger (corporate) patrons it's even better.

[chadwhitacre]

@daxter You're right. :-) Title changed.

[chadwhitacre]

+1 from @shurcooL in private email.

[mvdkleijn]

+1 from me... but please do this for non-US accounts too 😄

[MikeFair]

Going direct is really the way to do this.

I'd to see us doing this via openACH; International can be done for non-EURO countries; EURO countries require a separate system called "STEP2" which is likely to be in the works but could use someone who has actually done it to get the required formats and bank protocols configured into OpenACH.

People expecting to pay in via ACH would be required to prefund their accounts.

ACH takes a day or two (or three or four depending on weekends and holidays) to "settle" before the funds are available to be transferred out. Basically this means the existing concept of "charging the credit card accounts and transferring the money to people on that same day" can't be done.

The best idea to take care of this would be for givers to expect to prefund their accounts and each payday deducts from their balance.

if we combined this with the "funds" solution (#1493), then people can set a fixed amount they pay-in periodically and the funds take care of distributing that amount out over time until the next recurring payment. So if someone says I give $60 every 6 months then there's an ACH pay in transaction for $60 (which OpenACH will execute on a schedule for us); we'll see the record of that transaction succeeding and increase that user's balance $60.

The funds system knows that user pays in every 6 months and so prorates the deduction from that $60 over the coming ~24 weeks ($2.50 per week) and then prorates that $2.50 out over all the people you're currently tipping each week.

[bruceadams]

I like the idea of letting people push money into Gittip. This helps some of the use cases people want for one-time tips #5.

The last sentence of @MikeFair's recent update talks about prorating payouts. I'm not sure what I think of that idea, but is a separate thing from pay-in. We should allow our customers to put money in arbitrarily and tip absolute dollar amounts until there balance goes to zero. Let people manage the movement of their money.

[zbynekwinkler]

I like the idea of letting people push money into Gittip.

@bruceadams Isn't that like 👍 for #113?

[sferik]

👍 This would reduce the amount I pay in transaction fees from about $200 down to $78 annually. That’s more money that could be going toward open source contributions.

[chadwhitacre]

Do we get instant transfers from Balanced ACH? Is the money ours to work with after the API call is done, or is there a lag?

[MikeFair]

There's always at least a one day lag and can be as much as 3 banking
business days. The funds must "settle" before they can be moved again.

Credit cards have the same issue actually (not to mention the possibility
of charge backs).

What's happening now to make it look like the funds are "instantly
available" is Balanced fronts the cash to make it appear like instant
availability and then gets paid back when the money actually comes in. The
credit card company is also able to confirm the balance on the credit card
right away; and has a prearranged relationship to charge interest with the
credit holder for insufficient funds, which both serve to increase the
likelihood of txn success.

The fact is there has always has been a lag in the banking system; at least
for interbank transfers because the banks have to send messages to each
other and that process simply takes time; at least one day (intrabank
transfers on the other hand can oftentimes be instant because it's
internally held on the same system).

In short credit cards = high fees, bank account transfers with instant
availability = high fees (because instant bank transfers simply can't be
done, so someone is providing you credit to make their money availible now).

The solution to is reducing the number of txns and using less expensive
money transfer systems (which generally mean slower). ACH will cost about
$0.25 / txn regardless of txn amount (and will go down over time from there
as volume increases). So for a single person, at its absolutely most
expensive, doing both a payin and a payout every week, that's $26/year; and
more likely it's closer to $13/year or less because there isn't a bank
transfer going both directions every week.

Unless you use Balanced where they collect a percentage of the txn amount
as part of their fee in addition to the fixed amount.

To make ACH work; any giver wishing to save on transaction fees has to be
working out at least one week ahead (and preferably even longer out than
that).

So one way to account for this is having this week's payday initiate a
collection request via ACH for the following payday (which gives the donor
7 days to deal with handling any txn failures) and then it gives out the
funds that have actually settled.

Another mrthod would be to issue the ACH txns right away and then track the
txn status until it has settled (OpenACH does this automatically).

Even better though is to completely separate the payin process from the
payout process.

Let people initiate a payin to their balance at any time. It can even be
on a recurring schedule (which OpenACH will automatically take care of).
Then do payouts from whatever their current balance is.

Attempting a system that is taking in payments every week that aren't ever
going to fail and are always instantly transferring them out is something
even the banking network can't do at the moment. The only way to fake it
is to front the cash and then collect it back later (which is what balanced
is doing today) or simply telling people after the fact when they can do
nothing about it that didn't work.

No, the best answer is to start precharging people's accounts. Start
loading up the system so the funds are available and communicating that
state to folks in advance.

Mike
On Dec 29, 2013 8:06 PM, "Erik Michaels-Ober" [email protected]
wrote:

[image: 👍] This would reduce the amount I pay in transaction fees from
about $200 down to $78 annually.

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/777#issuecomment-31332787
.

[dmitshur]

Nice write up Mike.

[chadwhitacre]

Here's the Balanced docs for this:

https://www.balancedpayments.com/ach-debits

Lag, as @MikeFair says.

[MikeFair]

Using prefunded balances also helps to eliminate issues #113 and #1093.

[bruceadams]

+1 from Julio Rios via [email protected]

[chadwhitacre]

We're guinea pigging this with @rachelwalexander. Here's the relevant ticket in Freshdesk (login required). We've manually gone through the account verification workflow using the Balanced dashboard. I'm looking for the best way to ensure that we don't drain her funds back to her bank account next payday. We could set balanced_customer_href to null, but it really doesn't seem right not to be able to link over to her Balanced account from her Gittip account.

The alternative is to start building out some schema to keep track of the funding flows each user desires (#1063).

[seanlinsley]

To have a robust, automated solution we're definitely going to need to allow the user to set their own rules for when money we charge and credit them.

[chadwhitacre]

Bumping up from ★★☆ to ★★★ since we're actually trying to do this now.

[chadwhitacre]

Over at #2134 (comment) I manually disconnected @rachelwalexander's bank account. Dropping back to ★★☆. Unfortunately this is cumbersome enough that I don't think we should offer it as a general service that we perform manually.

[chadwhitacre]

+1 on gratipay/inside.gratipay.com#60.

[chadwhitacre]

+1 from @gdb in private email.

[rohitpaulk]

+1 on https://gratipay.freshdesk.com/helpdesk/tickets/1528

[mattbk]

+1 on https://gratipay.freshdesk.com/helpdesk/tickets/4494

Several of the companies that want to support the project are not willing to make payments using a credit card. Instead, they prefer to use a traditional invoicing process. That brings me to my question.
Does Gratipay accept payments by invoicing the contributing entity? As an alternative, does Gratipay accept payments via ACH?

[mojavelinux]

👍 to ACH payments from contributors.

[nobodxbodon]

Re-ticketed to gratipay/inside.gratipay.com#974 for further discussion and planning. After deciding on concrete implementation plan and dev work starts, this will be reopened for tracking purpose.