# 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](/documentation/originating-checks) and for [checks you printed yourself](#checks-without-check-transfers). Increase then evaluates whether the deposit should be allowed and creates a Transaction or Declined Transaction accordingly.

## Lifecycle

Inbound Check Deposit status lifecycle

|                      |                                                                                                                                                                 |
| -------------------- | --------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| `pending`            | The deposit has been received and is awaiting evaluation.                                                                                                       |
| `accepted`           | The deposit was accepted and funds were removed from the Account.                                                                                               |
| `declined`           | The deposit was declined and a return was sent to the depositing bank.                                                                                          |
| `returned`           | The deposit was accepted but later returned to the depositing bank.                                                                                             |
| `requires_attention` | A rare status set when the deposit needs manual intervention from the Increase team. [More about requires_attention](/documentation/requires-attention-status). |

## 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](/documentation/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.
