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.
- 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 ofpending_reviewing
. - A Pending Transaction is immediately created for the full amount of the transfer in order to hold funds.
- Once the transfer passes through internal reviews, the status updates to
pending_submission
. - When the file is submitted to the check printer, Increase updates the Check Transfer object with its
submission
details and the status is updated tosubmitted
. - When the check is mailed by the printer, Increase updates the Check Transfer object with its
mailing
details and the status is updated tomailed
. - 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 todeposited
. (For more on this, see “Evaluating deposit attempts” below.) - 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 mailed
and 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
ofcheck_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
ofcheck_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.