Cowrie Research

reap

4 min read

Reap

  • Name: Reap
  • URL: https://reap.global/
  • Category: modular fintech infrastructure / stablecoin account-and-card control plane / compliance and ledger API
  • Tags: ethereum-ecosystem solana-ecosystem
  • Summary: Reap is best kept as a product note for the account, card, deposit, webhook, and reconciliation mechanics exposed through its unified API. The named operator boundary now lives in reap.
  • What it does:
    • Lets partners create user- or company-owned spending accounts that back card programs and track available balance as assets minus liabilities
    • Supports multichain stablecoin deposit funding, with docs explicitly covering supported assets on Ethereum and Solana in production plus sandbox test assets on Ethereum Sepolia and Solana Devnet
    • Exposes KYC/KYB onboarding, user/company application workflows, account creation, card issuance, freeze/unfreeze, 3DS challenge handling, shipping, and reconciliation APIs
    • Provides webhook events for deposit lifecycle changes, account/card status changes, and card transaction lifecycle updates so integrators can stay in sync without polling
    • Uses a unified versioned REST API with bearer-key auth and a required Reap-Version header
    • Supports both direct stablecoin-funded accounts and prefund-style projects that allocate virtual assets from a master collateral account
    • Documents debt-clearing and reconciliation flows that burn virtual assets against outstanding card debt, which shows the product is managing account and settlement logic rather than only exposing a wallet or card façade
  • Key claims:
    • The docs introduction describes Reap as Modular fintech infrastructure. Cards, wallets, compliance, and payments via a single API.
    • The introduction says partners can launch card programs, onboard users with built-in compliance, accept stablecoin deposits across multiple chains, and track everything in a unified ledger
    • The accounts overview says an account is the unit of spending in Reap, every card is issued against an account, every authorization is evaluated against an account balance, and balance is computed as availableBalance = assets - liabilities
    • The accounts overview also distinguishes direct stablecoin deposits from prefund virtual-asset allocation models, which is a strong clue that Reap is a financial control plane rather than only a deposit API
    • The deposits guide says supported tokens sent to deposit addresses move through PENDING, CONFIRMED, and APPROVED states, with webhook notifications at creation and each status change
    • The supported-assets page documents production support for USDC and USDT on Ethereum and Solana and notes active expansion of supported chains and tokens
    • The webhooks docs describe a signed event system with HMAC verification, exponential retry over roughly 48 hours, and events spanning KYC/KYB, deposits, account state, and card transactions
    • The reconciliation API explicitly clears outstanding card debt by burning submitted virtual assets, which shows Reap is handling settlement and ledger semantics, not just issuing cards
  • Whitepaper: No canonical standalone Reap whitepaper or litepaper surfaced in this pass. The clearest current source of truth remains the official docs corpus, with the broader operator-side source capture now in ../whitepapers/reap-primary-sources-2026-04-30.md and ../whitepapers/reap-company-primary-sources-2026-08-13.md.
  • Sources:

Internal linkages

  • Company / operator boundary for KYB/KYC, licensing posture, card-policy workflow, and the broader treasury shell: reap.
  • Best same-slice reads: gnosis-pay and baanx.
  • Useful operator-side contrast: rain.

Protocol / company boundary

  • Keep this product note on the API and workflow mechanics: account objects, deposit approval states, supported assets, card lifecycle endpoints, webhook event shapes, prefund-versus-direct-funding models, and reconciliation semantics.
  • Use reap for the named operator boundary around customer admission, business-account packaging, legal and licensing shell, card and spend-control policy, and the signed callback workflow integrators trust in production.
  • That split matters because how do Reap accounts, cards, and reconciliations work? and which company controls access, policy, and production workflow around them? are related but not identical questions.

Control surface

  • At the product layer, practical authority sits in account issuance semantics, deposit approval state, supported asset coverage, prefund-versus-direct-funding mode, webhook event publication, and the reconciliation path that turns virtual assets into cleared card debt.

  • The thicker company-run shell around KYB/KYC, licensing, business-account onboarding, spend controls, and operational truth now points upward to reap.

  • Read Reap here as account-and-card control-plane middleware, not as a neutral payment rail.

  • Last reviewed: 2026-08-13 UTC

Graph View

Backlinks