Originating checks

Lifecycle

Status	Description
pending_approval	The transfer requires approval from a member of your team.
pending_reviewing	The transfer is pending review by Increase.
pending_submission	The transfer is pending submission to the check printer.
pending_mailing	The physical check is queued for mailing.
mailed	The physical check has been mailed.
deposited	The physical check has been deposited.
returned	The transfer has been returned.
canceled	The transfer has been canceled.
rejected	The transfer has been rejected.
stopped	A stop-payment was requested for this check.
requires_attention	The transfer requires attention from an Increase operator.

Sending a Check Transfer with Increase

Originating a Check Transfer via the Increase API kicks off several steps involving you, Increase, the Federal Reserve, and the receiving bank.

1. You make a POST /check_transfers call with the details of how much you'd like to send and data about the recipient. A Check Transfer is created with a status of pending_reviewing.
2. A Pending Transaction is immediately created for the full amount of the transfer in order to hold funds.
3. Once the transfer passes through internal reviews, the status updates to pending_submission.
4. When the file is submitted to the check printer, Increase updates the Check Transfer object with its submission details and the status is updated to submitted.
5. When the check is mailed by the printer, Increase updates the Check Transfer object with its mailing details and the status is updated to mailed.
6. Once the recipient deposits the check, Increase creates an Inbound Check Deposit object and decides if the deposit should be allowed. If so, we populate the Check Transfer object’s accepted_inbound_deposit_id attribute and update its status to deposited. (For more on this, see “Evaluating deposit attempts” below.)
7. A Transaction is immediately created for the full amount of the transfer and funds are removed from your Account. The Pending Transaction is marked as complete.

Printing your own Checks

By default Increase will print and mail your checks and you will be able to access all physical_check details on the Check Transfer object. A typical printed check will look like the image below:

Alternatively, you can print your own checks by setting the fulfillment_method to third_party when creating a Check Transfer. When this is set, the Check Transfer status will be set to mailedand you will be responsible for printing and mailing a check with the provided account number, routing number, check number, and amount.

Stop payment requests

You can make a stop-payment request on a Check Transfer any time before a check is deposited. After a request has been sent, the check is immediately voided and the Check Transfer status is updated to stopped with additional stop_payment_request details provided. The Pending Transaction status updates to complete, and no additional Transactions are created.

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:

• 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).

Approvals

For transfers that require approval from another team member, the Check Transfer is created with a status of pending_approval and a Pending Transaction is created to hold funds.

If the transfer is approved, the Check Transfer object updates with its approval details, the status is changed to pending_reviewing, and things progress normally.

If the transfer is not approved, the Check Transfer object updates with its cancellation details and the status is changed to canceled. The Pending Transaction status updates to complete, no transfer information is submitted, and no additional Transactions are created.

Reviews and rejections

Occasionally a Check Transfer will need to be manually reviewed by an Increase operator. When this occurs the Check Transfer object status will be set to pending_reviewing .

Once reviewed, the status changes to pending_submission and things progress normally. However, rarely a Check Transfer may be rejected by Increase. When this occurs the Check Transfer object status updates to rejected, no transfer information is submitted to the printer, and no additional Transactions are created.

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.