Docs
Guides
Explanatory and how-to content
API Reference
Technical documentation
Changelog
Release notes
Dashboard
Manage your account
Status
Service status
Guides

Receiving an ACH transfer

An ACH transfer sent to your Increase account creates an Inbound ACH Transfer. When an Inbound ACH Transfer is created or updated, your application can receive a webhook Event. You can action on these events to decline or return the Inbound ACH Transfer as needed. This means you can verify these transfers and manage funds when you see an Event come in.

Details about creating an ACH Transfer are described here.

Lifecycle

Inbound ACH Transfer statuses

StatusDescription
pendingThe Inbound ACH Transfer is awaiting action. It will transition automatically if no action is taken.
declinedThe Inbound ACH Transfer has been declined.
acceptedThe Inbound ACH Transfer is accepted.
returnedThe Inbound ACH Transfer has been returned.

Actioning

The Inbound ACH Transfer is created in a pending state. There's a one hour window where you can decline the transfer.

After an hour if you don’t take any action the transfer will automatically resolve. If the transfer moves into an accepted state, money moves in your Increase Account and a Transaction is created. Conversely, the transfer could be automatically rejected for a variety of reasons (insufficient funds, incorrect account details, etc.) and move into a declined state. If the transfer is accepted, you can also action to return it.

Declining

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

It’s useful to note that you’ll have a window of an hour by default to action on a pending transfer before it automatically resolves to the next status and is no longer eligible to be declined. 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 state, you can return it by using the POST /inbound_ach_transfers/:inbound_ach_transfer_id/transfer_return endpoint.

It’s useful to note that Inbound ACH Transfers can only be returned up to a cutoff date of 2 days after the transfer’s effective date. You can listen for the Inbound ACH Transfer updated webhook Event, run application logic, and hit this endpoint as needed.

Examples

Preventing an insufficient funds Inbound ACH Return

Your vendor sends you an ACH Debit for $100.

  • An Inbound ACH Transfer is created in a pending state 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.

After the hour cutoff, the Inbound ACH Transfer automatically resolves.

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

Rejecting an unauthorized transfer

An unauthorized party sends you an ACH Debit for $100.

  • An Inbound ACH Transfer is created in a pending state 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 the transfer and no money movement in your Increase account occurs.

  • The Inbound ACH Transfer moves to a declined state.

Returning a duplicate transfer

A buyer wants to settle a $100 bill, but instead of sending one ACH Credit two are accidentally sent.

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

An hour passes and no action is taken, the transfers resolve to accepted and money moves.

  • The Inbound ACH Transfer moves to an accepted state 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 an accepted state 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 a returned state.
  • A transaction for -$100 is created.