Deposit a check
In this tutorial, you'll learn how to:
✅ Deposit a check
✅ Handle rejected checks
If you are new to check management we recommend you read the check management overview before starting this tutorial.
The tutorial assumes you have a knowledge of APIs and how they work. For more information on sending API calls, see the API overview page .
The tutorial uses these API endpoints
API | Description |
|---|---|
Provides the necessary information and images to deposit a check |
The tutorial uses these webhooks.
Webhook | Description |
|---|---|
Check.Payment.Sent | A check deposit was sent to the Federal Reserve for clearing |
Check.Payment.Rejected | An outbound check wasn't processed due to compliance reasons or rejection by the Federal Reserve |
Check.Payment.Returned | Receiving bank returned a check to the sender |
Make sure you have:
- Cross River bank account number
- Images of the front and back of the check in Base64 (C9 check) format
To receive the webhook events for this tutorial both partner accounts need to register each specific webhook event type. Once you are registered, the event objects are sent to the registered URLs.
The event object contains a list of resource identifiers used to download details on each event.
In this tutorial you're a Banking-as-a-Service (BaaS) partner that offers a deposit account product to consumers. Your app allows your customers to perform mobile deposits. One of your customers just made a $1 check deposit into their account using your app, which is calling the CR system to pass the deposit details.
Call POST /Checks/v1/payments. For this call, you must supply the number of the account where the check is being deposited and images of both the front and back of the check as Base64-encoded values. A full list of attributes is found here .
A successful API call returns a JSON response with the details of the check. The status attribute in the response only tells you that the payment was created. It's not an indicator of a successful payment. The id attribute provides you with the payment ID. In this case, it's 9a44fdbf-89e2-4300-8f05-ad9501439bb1. The schedule attribute shows the schedule for paying the deposit into the account.
The CR system executes its OCR process to convert the check images into a format that complies with Federal Reserve Standards. CR sends the check deposit to the Federal Reserve for clearing, which triggers theCheck.Payment.Sentwebhook event. Note that the payment ID appears in theresourcesarray.
If you are registered for the Core.Transaction.Completed webhook event, you also receive that webhook at this point. When the check payment is released to the Federal Reserve, the CR system executes the core transaction related to the payment. This does not mean the funds are available. The schedule attribute in the response indicates the availability schedules of the deposited funds.
A check is systemically validated for compliance when you deposit it, for example the system verifies that the check has a valid MICR number. Results of this validation appear in the body of the response to the deposit request. Non-compliant checks are rejected and the rejection reason appears in the rejectionReason field.
Check rejection triggers the Check.Payment.Rejected webhook event. In this case the payment ID is b9e53e1c-683e-469c-8f79-ad8800f1ccc.
As already described, the rejection reason appears in the rejectionReason field of the event. In the example above, the check payment is rejected because of Duplicate. Address any check issues with the customer prior to resubmitting the check deposit to avoid subsequent rejections.
