Overview

    sequenceDiagram

    participant M as Merchant/LMS
    participant A as Auth
    participant F as Flex API / CORE
    participant O as Flex OPS Team
    participant B as Bank
    
    critical Verification
        M->>A: 1. Request Token
        A->>M: 2. Token Verified + Sent Back
    end


    M->>F: 3. Send Transaction(s) to Flex
    Note over F: Queued
    F->>M: 4. Transaction confirmation sent back

    
    F->>O: 5. Send Payment Info
    Note over O: Verification
    O-->>M: 6. ItemStatus updates to "S" when item is ready to be sent to Bank
    O->>O: 7. Built Files
    O->>B: 8. Send payment files

RCC Transaction Example

Remotely Created Checks (RCCs) are digital check payments initiated on behalf of the borrower, without requiring a physical signature.

This section walks through the life of a RCC transaction, including how to integrate with our API, and what to know about creating, retrieving, and voiding RCC payments.

1. Create a RCC Transaction

Model:

flowchart TD
    merchant[Merchant/LMS]
    api[FLEX API / CORE]

    merchant-->|Send transactions|api
    api-->|Receive confirmation sent back|merchant

Creating a RCC transaction begins with submitting payments in either single or bulk.

2. Formatting & Submissions

Model:

flowchart TD
    merchant[Merchant/LMS]
    api[FLEX API / CORE]
    ops[FLEX OPS TEAM]

    merchant---->|Send transaction to Flex|api
    api-->|Processes send transaction|ops
    api---->|Send back confirmation|merchant

Behind the scenes:

• The transaction is formatted into a check-like structure
• It is added to a daily clearing batched
• The batch is transmitted to the check clearing network

Cutoff Time

RCC cutoff times vary by provider. Check with provider for specific times.

Clearing Times

Clearing typically occurs on business days only and may take 1-3 days depending on bank speed.

2. Retrieve a RCC Transaction

There are many ways to view the status of a transaction and parameters, so please check our page for getting transactions and use the desired endpoint.

3. RCC Transaction Statuses

Possible statuses include:

• B: Blocked - Our pre-processing validation determined the transaction is blocked due to the State, Routing Number, or Account Number.
• I: Invalid - The transaction cannot be processed or transmitted due to a pre-processing or validation issue.
• R: Returned - The transaction has been returned and you may use the Return Reason and Return Message field to determine the cause.
• S: Settled - Transaction is validated and prepared to be sent to the bank. At this point, you may assume the item will settle on the settle date unless the bank sends back a return on a later date.
• V: Voided - Voiding a transaction is similar to deleting it, except it will remain viewable in the system. These items will not be processed, nor will they show up in reporting.
• W: Waiting - Transaction is awaiting validation and pre-processing. If all validation passes, the item will be queued up for Bank transmittal and the ItemStatus will be updated to ‘S’ Settled. If the transaction fails these checks, the status will be updated to one of the following: ‘B’ Blocked, ‘I’ Invalid, or ‘R’ Returned.

If the transaction is returned, you’ll receive a return code and a timestamp indicating when the return was processed.

Return Codes

You can view the full API documentation in our Swagger Collection. This collection provides detailed information about all available endpoints, including request and response schemas, parameters, and examples.

4. Void a RCC Transaction

Voiding a RCC transaction is only possible before it is batched or submitted to the network. Once submitted, the transaction is out of our hands and must follow the return process.

View our page for voiding transactions and use the desired endpoint.

If a transaction successfully voids, the status will be updated to voided.