Account Management

Overview

As a platform client using Reap Connect, you will first be given a Manager Account. You must then create a Managed Account for each end user (your client) that is going to send payments via Reap (this must be your direct client and the entity originating the payment for themselves, the Managed Account cannot be an intermediary). The creation and management of Managed Accounts are done via the Business Account API endpoints. Please note you cannot send payments on behalf of your clients via your own Manager Account.

Creating a Managed Account

sequenceDiagram 
    participant EU as End User
    participant C as Client
    participant API as Reap
    
    EU->>C: Sign up/Request payment feature
    C->>API: POST /business-account
    API-->>C: Return unique Business ID (BUUID)
    C->>EU: Account creation in progress
    API->>API: Review account creation request
    API-->>C: Webhook triggered
    Note over API,C: "eventType": "account_information"
    Note over API,C: "eventName": "account_status_update"
    C->>EU: Account created/rejected

For each end user, you must send a POST /business-account request to our API to create a unique business account (Managed Account) in our system. When creating a business account with Reap, you will be required to share the data below:

• The end user's business name
• The end user's registered business address (cannot be a P.O. box address)
• A registered business identifier, either a Tax ID or business entity ID
• Confirmation of end user's acceptance of Reap's terms of service (achieved via logging date and IP address)

Upon receiving the first successful response from the POST request, the API will generate and return a unique Business ID (BUUID), which must be used in the header for all subsequent API calls related to this Managed Account (including to update a business account). After the Managed Account is created, you will be able to see this account in your Reap dashboard (top left hand side via the multi-entity drop down).

Once the account review is complete (this happens once all necessary information, including Ts&Cs acceptance confirmation, is provided), we will trigger an account information webhook to you with the result - when the account has the "active" status, then core functionalities are enabled (create blockchain addresses, receiving parties, and payments). For Sandbox integration, you can simulate activations and rejections via the account status simulation endpoint.

You as the platform are responsible for properly presenting Reap's Terms and Conditions to each of your end users when creating a Managed Account. This means:

• Including both of the following Ts&Cs documents as hyperlinks:
  • General Terms
  • Managed Account Terms
• Implementation Option 1: Explicit acceptance during onboarding flow
  • This would be a checkbox (or similar component that needs to be clicked/chosen) that explicitly confirms acceptance to Reap's Ts&Cs
  • This can happen during a general KYB onboarding flow on your platform or a feature-specific enablement flow
  • Example language: "I accept Reap's General Terms and Connect - Managed Account Terms."
• Implementation Option 2: Clearly embed Reap's Ts&Cs links into your Ts&Cs
  • This means that you will link to Reap's Ts&Cs within the Terms & Conditions that you present to your end users during KYB/feature-specific onboarding
  • Reap's Ts&Cs should be clear, legible, and available within your Ts&Cs document
  • Example language: "By using services offered by the Reap platform, you agree that you have read, understood and accept Reap's General Terms and Connect - Managed Account Terms."

During the implementation phase, as part of going live with your first end user and beginning to transact, we will help make sure the business accounts and Ts&Cs are properly implemented.

Funding Payments in Your Accounts

You can only generate payments from a Managed Account (not a Manager Account) - if you are a Manager and would like to make payments, please create a Managed Account with the same legal entity information as that of your Manager Account.

Each Managed Account has its own wallets/blockchain addresses to send funds on-chain, and that is the primary method for funding payments created for that Managed Account. Please note that when funding a payment(whether ahead of time or when the payment is in "Awaiting Funds" status), the source currency upon payment creation must match the currency whose balance you are increasing.

You can also directly transfer funds between a Manager Account and a Managed Account using the Transfer funds functionality. This allows a Manager Account to top up a Managed Account directly, or a Managed Account to push funds back to its Manager Account.

A second method for funding a Managed Account payment is to set the Payment object parameter useManagerFunds to TRUE. What this does is it allows a payment to check for available balance (in matching source currency) not just in its Managed Account, but also in the Manager Account, and then automatically trigger an internal transfer for any amount needed to finish settling the payment. This feature is helpful for:

• Streamlining the funding of many Managed Accounts: All payments across all Managed Accounts could have this parameter designated as TRUE, so you only need to fund the Manager Account (in the appropriate currency) instead of multiple Managed Accounts
• Streamlining Manager --> Managed account transfers: If you are subsidizing or rebating part of your client's payment fees, this feature allows you to automate the "top-up" of the payment fees without having to trigger a transfer for each payment.
• Streamlining Manager and Managed Account funds management: You can treat the "Manager Account" as an account whose balance is only for your funds, while the Managed Account has funds only from your end user (this is particularly helpful if your setup is one where you aren't in the flow of funds). From your Manager Account balance which is segregated from the Managed Accounts, you can then manage the funding of fees (e.g. fees to Reap) accordingly and in a way that creates a transfer (and data record) for each fee-related internal transfer.

When making use of the Manager --> Managed Account automation, both accounts will indicate the outgoing/incoming internal transfer in their balance movements and reports, and for which payment the transfer was done. The payment activity itself, including payment history, tracking, and details, will still only be available within the Managed Account that contains that payment (payments aren't available within the Manager Account). When Reap cancels a payment, funds are always refunded to the dedicated wallet of the account that originally created the payment. This refund behavior is consistent regardless of the useManagerFunds setting or which account's funds were actually used to fund the payment.