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 an RCC transaction, including how to integrate with our API, and what to know about creating, retrieving, and voiding RCC payments.

Step 1. Create an RCC Transaction

Model:

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

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

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

Step 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

Step 3. Bank Processes the RCC

Model:

flowchart TD
    ops[FLEX OPS TEAM]
    bank[Bank]

    ops-->|Built Files|bank

The borrower’s bank receives the check data and processes it as a traditional debit. One of two things happens:

Accepted: The bank debits the funds.
Returned: The bank rejects the item.