Skip to main content
In an External-mode project you own the money decision on every card transaction. Reap calls your endpoint, you return an approve or decline, and Reap relays that decision to the card network. Your systems are the source of truth for the per-user balance, the risk decision, and the per-user ledger - Reap keeps no per-user balance of its own to authorize against. Reap does not step out of the loop, though. It still enforces its program-wide guardrails on every transaction before and around your decision - card and account state, your spend policies and limits, fraud monitoring, card-network rules, and the master collateral that backs the program - any of which can decline a transaction regardless of your answer. See Division of responsibility.
Applies to Program-Funded projects using External authorization mode. In Managed mode Reap authorizes against the balances you allocate, and these pages do not apply.

​
Division of responsibility

External authorization is a split contract. Reap still runs the deterministic, program-wide guardrails; you own the money decision. Reap runs its deterministic guardrails - card state, spend policies, and limits - before it calls you, so your endpoint is only asked about transactions that have already passed them; you never see one Reap has already declined. Card-network rules and fraud monitoring apply on top and can decline a transaction independent of your answer, including before your endpoint is ever called. That leaves your endpoint exactly one question: given the transaction in front of you, does the cardholder have the balance and do your own controls allow it?

​
How it works

​
The authorization flow

1

A cardholder pays

The cardholder taps, swipes, or enters their card. The card network routes an authorization request to Reap through the card processor.
2

Reap runs its local checks

Reap validates card and account status, evaluates your spend policies, and applies platform limits. Anything that fails is declined locally with a decline reason and never reaches you.
3

Reap calls your endpoint

Reap sends a signed CARD_AUTHORIZATION_REQUEST as an HTTPS POST to your registered endpoint, carrying the card, amount, and merchant details.
4

You make the decision

Check your own ledger balance and risk controls, then return APPROVE or DECLINE within 1.6 seconds. See Handling requests for the response contract and latency budget.
5

Reap confirms collateral

If you approve, Reap verifies your master collateral account covers the spend. In the rare case it does not, Reap declines regardless of your approval.
6

Reap relays the outcome

Reap forwards the approve or decline to the card network, which releases the goods or declines at the terminal.
7

Reap notifies you asynchronously

If the transaction was approved, the transaction lifecycle begins: a CARD_TRANSACTION_CREATED webhook, then CARD_TRANSACTION_UPDATED for each clearing, reversal, or refund. These are the durable record you reconcile your ledger against - the authorization request is the live decision, not the record.

​
Next

The authorization request

The request and response contract: envelope, payload, decline reasons, timeout, and fail-closed behavior.

Handling requests

Build an endpoint that stays fast, verifies signatures, and dedupes safely on the authorization hot path.

Keeping your ledger in sync

Reconcile holds, clearings, reversals, and refunds against the async transaction lifecycle.

Setup and testing

Register your authorization endpoint and exercise it end to end in sandbox.