Skip to main content
In a Program-Funded project you choose who makes the authorization decision on every card transaction: Reap, against the balances you keep in sync (Managed), or your own systems, in real time (External).
Authorization mode applies only to Program-Funded projects. User-Funded projects are always authorized by Reap against the user’s deposited balance. Like your funding model, authorization mode is set at project setup and cannot be changed after launch.

​
The decision point

Whenever a cardholder taps, swipes, or checks out online, the card network asks Reap to approve or decline the transaction within a tight time budget. Authorization mode decides who answers.

​
Managed

Managed is the default, and most programs should use it. Reap evaluates and answers every authorization inside the card network’s window, so you never build or operate a real-time authorization service or card-processing stack. You mirror each user’s spending power into Reap as Virtual Assets; Reap then authorizes each transaction against that balance, enforces your spend policies and platform limits, places and releases holds, and clears, reverses, and refunds against the same balance. Because the balance lives in Reap, the account exposes a readable spendable figure you can surface to the cardholder directly. Managed fits when:
  • You want Reap to own the authorization decision and the balance it draws against.
  • Mirroring per-user balances into Reap (via Virtual Asset postings) fits how you operate.

​
External

In External mode you make the decision. On every authorization Reap calls your endpoint with the transaction details and relays your approve or decline back to the card network. Your systems stay the source of truth for balance and risk, and you do not allocate Virtual Assets. External fits when:
  • You already run your own ledger, risk, or balance engine and need it to be authoritative.
  • You cannot or do not want to mirror per-user balances into Reap.
  • You need to act at authorization time in a way only your systems can, such as moving user funds or drawing on a credit line.
  • You already integrate this way with another card issuer and want a symmetric integration.
External gives you more control, and more responsibility. It is not an upgrade over Managed. In return for owning the decision you take on:
  • An always-on endpoint on the authorization hot path. Reap calls you synchronously on every authorization and you must return a decision within 1.6 seconds. Time out, return a non-2xx, or be unreachable and the transaction is declined (fail-closed) - there is no retry on the live transaction.
  • Your own ledger. Because you make the final approve or decline, you run the system of record for user balances and risk on your side and decide against it in real time. Reap holds no per-user spendable balance in External mode, so the authoritative ledger is yours to operate and keep correct.
  • Reconciliation from the event stream. You keep that ledger in sync from the asynchronous transaction webhooks - authorizations, clearings, reversals, and refunds - rather than reading balances back from Reap.
See External Authorization for the request and response contract, registering your endpoint, fail-closed behavior, and sandbox testing.

​
Choosing between them

The distinction in one line: Reap is always the source of truth for spend - what actually cleared the network - while the source of truth for balance - what a user is allowed to spend - is Reap in Managed mode and you in External mode.

​
What stays the same in both modes

Authorization mode changes only who approves a transaction. In both modes Reap clears, reverses, refunds, and settles with the card network, applies your spend policies and platform limits, and emits the same transaction webhooks. Your funding model and program mode are unaffected.