Mobile Check Deposit allows customers to deposit physical checks by capturing images of the check and submitting them digitally.

The system processes these deposits through a series of automated and manual checks to ensure:

• Image quality and compliance
• Check authenticity
• Fraud prevention
• Successful bank clearing

How It Works

1. Customer captures check images (front & back) and enters the deposit amount.
2. Client app sends a request to PCE's Create Transaction API with images and optional metadata.
3. Next checks are forwarded for Image Quality Assessment (IQA) and endorsement (~2-5 seconds):
   1. Image Quality Assessment (IQA):
      1. Check the image clarity, Check 21 compliance, MICR visibility
      2. Extract amount, account, routing, and check number
   2. Endorsement:
      1. If vendor endorsement (default) → the system electronically endorses the checks,
      2. If you want to enable customer-endorsement or prefer your electronic endorsement → the checks submitted should be endorsed by you. Priority System will skip the check endorsement step.
4. Manual Review – triggered by information mismatches, duplicates, fraudulent or endorsement issues. Priority Ops resolves mismatches, duplicates, or fraud suspicions by accepting or rejecting the checks
5. Checks are sent to the bank for final clearing approximately every 15 minutes. The instructions should be received prior to cut off period to be processed for the same day. Reach out to your AM to know more on the cut off times. (The bank can still reject for non-image reasons like NSF, fraud, duplicate MICR issues).
6. Funds realization: Typically, 5–7 business days after deposit; bank may still return items.

Check Deposit Flow (Step-by-Step)

This section outlines the end-to-end flow of a check deposit, from submission to final settlement. It highlights each stage of processing, including validations, bank clearing, and potential return scenarios, to help you understand how a check transaction progresses through the system.

Step 1: Image Capture

The customer captures both the front and back of the check. Ensure the MICR data of the check is not a duplicate of a previously successfully processed check. The customer

• enters the amount to be deposited,
• (Optional) Provides checkType, checkNumber, auxiliaryOnUs, onUs (required if checkType is passed)

Key Points: 

• It is recommended to leave optional fields blank, allowing the system to automatically extract and validate details during Image Quality Assessment (IQA) in Step 3.
• A check may not be accepted if: 
  • Not in USD
  • Already deposited
  • Not readable or poor image quality
  • Missing required details
  • Older than 6 months or post-dated

Customer-side Image Validations

Before submission, ensure images meet the following requirements: 

Failure to meet these requirements will likely result in transaction failures during IQA (Step 3).

Step 2: Submit Deposit Request

Once images meet the requirements, use the POST /v1/customer/id/{id}/transaction (or externalId) API endpoint to initiate a transaction, including following key parameters: 

Check Images (Mandatory)

If processingDetail.isEndorsed is false, you can omit all MICR-related fields and allow the system to automatically extract check details during Image Quality Assessment (IQA).

Upon receiving the deposit request, the system performs a series of validations before the transaction is queued:

• Ensures the deposit amount does not exceed the limits configured for the customer’s account, the request is immediately rejected with an error response.
• Confirms the provided destination account is a valid account and is in an ACTIVE status. If the account is inactive, marks the transaction as PENDING.

If all validations succeed, the transaction request is accepted. The transaction status is set to SCHEDULED, and the Image Quality Assessment (IQA) process begins immediately.

785451<   123456789   0012345678   x`   000602
└─ Aux On-Us   └─ Routing #   └─ Account #   └─ Check #

9987776655   123456789   0012345678   602
└──── On-Us   └─ Routing #   └─ Account #

Step 3: Image Quality Assessment (IQA) 

IQA is a fully automated process that usually completes in ~ 2-5 seconds. The system checks image quality, Check 21 compliance, MICR accuracy as per standards. System then

• Extracts key details: Amount, Check #, Account #, Routing #
• Matches extracted details with any manual input shared at the time of creation.

Checks may not be accepted if they are: 

• in a currency other than US Dollars
• have already been deposited
• not readable
• have a very light ink which is not readable on scanning.
• checks without a date, have been post-dated, or are more than 6 months old

Possible Outcomes: 

Use the GET /v1/customer/id/{id}/transaction/id/{id} (or externalId) API endpoint or subscribe to the transaction.update webhook to get this information instantly.

1. VERIFIED Check Verification status
   1. Provided no optional details are shared → the extracted details are treated as the source of truth.
   2. Proceeds to endorsement step (Step 4)
2. FAILED Check Verification status

   1. FAILED with reason included in the processingDetail.checkVerification.statusReason node. 
      Check Verification Status and Status Reasons: 

      Status	Status Reason
      PENDING	PENDING_VERIFICATION
      VERIFIED	DOCUMENT VERIFIED
      FAILED	IQA Failure Processing error Cannot read check. Please retake the photo with steady hands, good lighting, and all four corners visible. The MICR line has an intrusion. Cannot find check in the image. Please retake. Ensure focus and four corners are visible. Submitted 2 images of the front of the check. Please retake both front and rear photos. Blurred image. Hold the camera steady or position it further away. Cannot read account data. Focus and include all corners in the image. Rejection based on manual review. INCORRECT_AMOUNT INCORRECT_ACCOUNT_NUMBER INCORRECT_ROUTING_NUMBER INCORRECT_CHECK_NUMBER OTHERS

   2. Transaction status: FAILED 

   3. If optional details (mentioned in Step 1) were provided and do not match extracted values → IQA Verification fails → Transaction sent for manual review by Priority Ops (Step 5).

   4. Customer should be asked to take corrective actions and initiate a new transaction in such cases by recapturing both the images.

Step 4: Submitted for Endorsement

After IQA verification, the system initiates endorsement: 

• Vendor Endorsement (Default) – The check is electronically endorsed by the vendor system and sent directly to endorsement verification.
• Self-Endorsement – If this option is enabled for your integration, this step is skipped.

The transaction will go for manual review if the endorsement process detects any of the following:

• Presence of endorsement (for self-endorsed deposits).
• Duplicate MICR line data across previously processed checks.
• Signs of alteration or fictitious checks.

Step 5: Manual Review 

The Priority Operations team inspects all the flagged transactions. Typical triggers include:

• Discrepancy between extracted MICR data and customer-supplied values during IQA verification.
• Duplicate deposits from the same or different customers.
• Possible fraud indicators.

During manual review, Ops team evaluates each case and take one of the following actions:

• If customer input mismatches actual check details → Reject with appropriate reason.
• If extracted data mismatches actual check → Correct vendor data and approve.
• If suspected fraud (duplicate, illegitimate check) → Reject with appropriate reason

Once review is completed:

• On Approval, transaction moves to PROCESSING status, and sent to the bank (Step 6)
• On Rejection, transaction moves to FAILED status with statusReason explaining the cause.

Use the GET /v1/customer/id/{id}/transaction/id/{id} (or externalId) API endpoint or subscribe to the transaction.update webhook to get this information instantly.

You can opt out of the manual review by the Priority Ops for IQA verification checks due to information mismatches, in which case the transaction will be marked as FAILED within 2-5 seconds and you can request the customer to recapture the image/details and share.

Endorsement failures are always manually reviewed by Priority Ops to identify fraudulent cases.

Step 6: Bank Processing & Fund Realization

Once a check passes IQA and endorsement verification, it is transmitted to the bank in batch files. These batches are processed by Priority and sent to the bank approximately every 15 minutes, ensuring timely clearing submissions.

• While the bank attempts to post the transaction to the issuing account, the transaction in PCE remains in PROCESSING state while awaiting confirmation from the bank.
• If bank accepts the deposit, funds are typically made available to the customer within 5–7 business days after the deposit date. This time frame can vary depending on bank processing times, weekends, and public holidays.
• Even after a check has been accepted and posted by the bank, it may still be returned if issues arise, such as
  • NSF (Non-Sufficient Funds)
  • Stop Payment instructions
  • Closed or Frozen Account at the issuing bank

Return Handling

During the 5–7 business day clearing period, the check is subject to bank returns.

a. If the check is returned within this period: 

• The transaction status is updated to FAILED, along with a corresponding statusReason.
• No funds are credited to the customer’s account.

b. If no return occurs within the 5–7 business day window: 

• The transaction is marked as COMPLETED.
• A credit ledger entry is created in the customer’s account to reflect the deposited amount.

c. If the check is returned after the transaction is marked as COMPLETED  :

• The transaction continues to remain in COMPLETED status, with an updated return statusReason.
• A debit entry is created in the customer’s account to reverse the previously credited amount.
• Return details are recorded and made available via the Return List API for reconciliation and reporting purposes.

Check Transaction Lifecycle Status

Best Practices

• Capture images in good lighting with no glare
• Ensure all four corners are visible
• Avoid manual data entry unless required
• Prompt users to retry immediately on failure
• Clearly communicate processing timelines (5–7 days)