Receiving an ACH transfer

An ACH transfer sent to your Increase Account creates an Inbound ACH Transfer. Your application can receive a webhook Event when one is created or updated, and can decline or return the Inbound ACH Transfer as needed.

Inbound credits and inbound debits

Inbound and outbound describe who originated a transfer. Transfers someone else originates against your Account Numbers are inbound, and Increase represents them as Inbound ACH Transfers. Transfers you originate are outbound, and are covered in sending an ACH transfer.

Every ACH transfer is either a credit or a debit. An ACH credit pushes money to the receiving account. An ACH debit pulls money from the receiving account. The Inbound ACH Transfer’s direction tells you which one you received.

	The originator is	Effect on your Account
Credit	Pushing funds to you	Funds are added
Debit	Pulling funds from you	Funds are removed

Both directions arrive as Inbound ACH Transfers, share the lifecycle below, and send the same webhook Events.

An inbound credit adds funds to your Account and rarely needs any action. An inbound debit removes funds, so you may want to evaluate these. You can decline inbound debits individually, or turn them off for an Account Number entirely, as described in blocking inbound ACH debits.

ACH directions covers all four combinations of credit or debit and inbound or outbound.

Lifecycle

pending	The transfer has been received and is awaiting settlement. It resolves automatically if you take no action.
declined	The transfer was declined and Increase returned it to the originating bank. No money moved.
accepted	The transfer settled and a Transaction moved the money: into your Account for a credit, out of your Account for a debit.
returned	The transfer was accepted but later returned to the originating bank, and a second Transaction offset the original Transaction.

Actioning

The Inbound ACH Transfer is created in the pending status. You can decline the transfer up to the expected settlement time.

If you don’t take any action, the transfer will automatically resolve when it settles at the Federal Reserve, following the FedACH settlement schedule. If the transfer moves into the accepted status, a Transaction is created and money moves into your Account for a credit or out of your Account for a debit. The transfer can also be declined automatically for a number of reasons (insufficient funds, incorrect account details, or inbound ACH debits blocked on the Account Number) and move into the declined status. Once the transfer is accepted, you can still return it. How long you have depends on the return reason, described in returning.

Blocking inbound ACH debits

Set an Account Number’s inbound_ach.debit_status to blocked to decline every inbound ACH debit sent to it. Increase returns these debits to the originating bank with return code R20 (Non-Transaction Account). Inbound ACH credits are unaffected. You’ll still see the Inbound ACH Transfer and its webhook Events, but you don’t need to act on them.

If you want to permit some inbound ACH debits and not others, leave debit_status set to allowed and decline the ones you don’t want while they’re pending.

Because you can create as many Account Numbers as you need, a common approach is one Account Number per counterparty, with debits blocked on the Account Numbers that should only ever receive funds. See tracking vendors.

Declining

When an Inbound ACH Transfer is in the pending status, you can decline it by using the POST /inbound_ach_transfers/:inbound_ach_transfer_id/decline endpoint.

You can decline a pending transfer until FedACH settlement occurs, following the settlement schedule. After that, the transfer automatically resolves to the next status and is no longer eligible to be declined. The transfer’s automatically_resolves_at field indicates when this will happen. You can listen for the Inbound ACH Transfer created webhook Event, run application logic, and hit this endpoint as needed.

Returning

When an Inbound ACH Transfer is in the accepted status, you can return it by using the POST /inbound_ach_transfers/:inbound_ach_transfer_id/transfer_return endpoint.

Most returns must be made within two banking days of the transfer’s settlement date. Unauthorized debits to consumer accounts can be returned for up to sixty calendar days. See return windows for details.

You can listen for the Inbound ACH Transfer updated webhook Event, run application logic, and hit this endpoint as needed. Returns you receive on transfers you originated work differently. See ACH returns.

Examples

Preventing an insufficient funds return on an inbound ACH debit

A vendor you’ve authorized pulls $100 out of your Account with an inbound ACH debit.

• An Inbound ACH Transfer is created in the pending status for $100.
• An Inbound ACH Transfer created Event is sent to your webhook subscription.

Upon receiving the Event, your application identifies that your Account lacks the required funds (you only have $30) to complete the transfer. If you did nothing, the transfer would be returned for insufficient funds. You decide to transfer $70 into the Account to bring the balance up to $100.

• A Transaction is created for $70 into your Account.

When FedACH settlement occurs, the Inbound ACH Transfer automatically resolves.

• The Inbound ACH Transfer moves to the accepted status.
• A Transaction is created for -$100 to pay the vendor.

Declining an unauthorized inbound ACH debit

An unauthorized party tries to pull $100 out of your Account with an inbound ACH debit.

• An Inbound ACH Transfer is created in the pending status for $100.
• An Inbound ACH Transfer created Event is sent to your webhook subscription.

Your application listens for the Event and sees the unexpected transfer. You decide to decline it, and no money leaves your Account.

• The Inbound ACH Transfer moves to the declined status.

Returning a duplicate inbound ACH credit

A buyer settling a $100 bill accidentally pushes two inbound ACH credits instead of one.

• An Inbound ACH Transfer is created in the pending status for $100.
• An Inbound ACH Transfer created Event is sent to your webhook subscription.
• An Inbound ACH Transfer is created in the pending status for $100.
• An Inbound ACH Transfer created Event is sent to your webhook subscription.

The settlement time passes and no action is taken, so the transfers resolve to accepted and $200 moves into your Account.

• The Inbound ACH Transfer moves to the accepted status and an updated Event is sent to your webhook subscription.
• A Transaction is created for $100 to settle the buyer’s bill.
• The second Inbound ACH Transfer moves to the accepted status and an updated Event is sent to your webhook subscription.
• A second Transaction is created for $100.

Your application listens for the updated Event and notices the duplicate transfer. You decide to return the duplicate to your buyer.

• The second Inbound ACH Transfer moves to the returned status.
• A Transaction for -$100 is created.