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

Inbound check deposits

When someone deposits a check drawn on one of your accounts, Increase creates an Inbound Check Deposit object and sends an inbound_check_deposit.created webhook for it. This happens both for checks you sent via a Check Transfer and for checks you printed yourself. Increase then evaluates whether the deposit should be allowed and creates a Transaction or Declined Transaction accordingly.

Lifecycle

pendingThe deposit has been received and is awaiting evaluation.
acceptedThe deposit was accepted and funds were removed from the Account.
declinedThe deposit was declined and a return was sent to the depositing bank.
returnedThe deposit was accepted but later returned to the depositing bank.
requires_attentionA rare status set when the deposit needs manual intervention from the Increase team. More about requires_attention.

Evaluating deposit attempts

When a recipient deposits a check, we create an Inbound Check Deposit object and send an inbound_check_deposit.created webhook for it. This object will start in a pending status and have an automatically_resolves_at timestamp attribute (by default, 1 hour after the object's created_at). After that time elapses, we evaluate a few conditions, called Positive Pay:

  • Is either the Account Number or Account that this deposit points to closed or inactive?
  • Has the Check Transfer been stopped?
  • Has the Check Transfer already been successfully deposited?
  • Does the Account have an insufficient current balance to cover the deposit?

If the answer to any of these questions is yes, we decline the deposit attempt:

  • The Inbound Check Deposit transitions to status: declined.
  • A Declined Transaction with a source.category of check_decline is created.
  • Under the hood, Increase sends a return to the depositing bank. The recipient will see a returned check and not receive funds. (They can also tell their bank to retry the deposit.)

Otherwise, we accept the deposit attempt:

  • The Inbound Check Deposit transitions to status: accepted.
  • A Transaction with a source.category of check_transfer_deposit is created.
  • The Pending Transaction associated with the Check Transfer is completed.

Custom evaluation logic

You can use the delay between the Inbound Check Deposit's created_at and automatically_resolves_at to fix any issues with the deposit - for example, you can just-in-time fund the underlying account via an Account Transfer if its balance is low. You can also use arbitrary logic inside your application to evaluate the deposit attempt yourself during that window. All of the information Increase receives about the check from the depositing bank, including deposit scan images, is included on the inbound_check_deposit object. You can decline the attempt via the API by making a POST to /inbound_check_deposits/:id/decline. (If you decide to approve the deposit, take no action and it will be automatically resolved as described above).

Returns

After a deposit has been accepted, you can return it to the depositing bank by making a POST to /inbound_check_deposits/:id/return with a reason. When you do, the Inbound Check Deposit transitions to status: returned, a new Transaction is created to reverse the funds, and — if the deposit was against a Check Transfer — the Check Transfer's status is updated to returned.

Checks without Check Transfers

While for most cases we recommend using Check Transfers for ease of bookkeeping and fraud prevention, in some cases you may want to process checks where you don't know the amount up front (such as printing your own checkbooks). To do this, all you need is an Account Number with the inbound_checks.status property set to allowed. Then, print and fulfill your own checks with that account and routing number (and whatever other details you need). When a recipient deposits one of these checks, we'll create an inbound_check_deposit object as described above (the check_transfer property on this object will be null), run the same evaluation logic, and create a Transaction or Declined Transaction. If you pursue this approach, we recommend implementing advanced evaluation logic as described above to make sure the deposits you see are what you expect.