Overview - Reap API

A policy is a rule Reap enforces when authorizing a card transaction. You decide what is allowed, attach the rule at the right level of your program, and Reap applies it on every transaction in real time. You do not run your own authorization service, and you do not need to react to each transaction as it happens. Reap makes the authorization decision. Policies are how you tell Reap what that decision should be.

What you can control

Policies fall into two families.

Restrictions

Block transactions by merchant (category, specific merchant, or country) or by channel (in-store, online, ATM, push-to-card). Evaluated against the single transaction in front of it.

Limits

Cap a single transaction amount, total spend over a period, or the number of transactions over a period. Periods are calendar windows from daily through yearly, plus lifetime.

See Control types for the full list and the configuration each one takes.

How policies work

Every policy has three parts:

A type, which decides what it checks (a merchant restriction, a spend limit, and so on).
A scope, which decides what it applies to: your whole program, one cardholder, or one card. See Scopes.
A configuration, the values specific to the type (the merchants to block, the amount cap, the window).

When a card is used, Reap gathers every active policy that applies to that card, from the card itself up through the cardholder and the program, and checks the transaction against all of them. If any one of them would block the transaction, it is declined. The strictest applicable rule always wins, so a permissive rule at one level can never loosen a stricter rule at another. A new card has no policies and is unrestricted, beyond the platform-enforced limits that apply to every program (see ATM withdrawal limits and Restricted MCCs). You add policies as you need them.

When a policy declines a transaction

A blocked transaction is recorded as DECLINED with a declineReason code that identifies which kind of rule stopped it, and a policy reference that names the exact policy responsible. The reference is captured on the transaction at decline time, so it stays accurate even if you later edit or remove that policy.

{
  "status": "DECLINED",
  "declineReason": {
    "code": "SPEND_LIMIT_EXCEEDED",
    "message": "This transaction would exceed the spending limit on this card. Try a smaller amount or try again later."
  },
  "policy": {
    "id": "9b7d3c2a-1f4e-4a2b-8c6d-0e1f2a3b4c5d",
    "type": "SPEND_LIMIT",
    "scopeType": "CARD",
    "name": "Daily card limit"
  }
}

See Decline reasons for every code a policy can produce.

Managing policies

Operation	Endpoint
Create a policy	`POST /policies`
List your policies	`GET /policies`
See what’s in force for a card, cardholder, or program	`GET /policies/effective`
Get a policy	`GET /policies/{id}`
Rename a policy	`PATCH /policies/{id}`
Replace a policy’s configuration	`PUT /policies/{id}/config`
Stop enforcing a policy	`POST /policies/{id}/disable`
Resume enforcing a policy	`POST /policies/{id}/enable`

Editing a policy

Most of a policy can be changed in place. A few properties are fixed at creation, because changing them would change what the policy fundamentally is.

Editable

Name, with PATCH /policies/{id}
Status, via enable / disable
Amounts, counts, merchants, and channels, with PUT /policies/{id}/config

Fixed at creation

Type
Scope
A limit’s calendar window

To change a fixed property, create a new policy and disable the old one. Replacing a limit’s amount preserves recorded usage: raising a daily spend limit from $500 to $1,000 mid-day does not reset what has already been spent, it just raises the ceiling.

Turning a policy off

To stop enforcing a policy, disable it with POST /policies/{id}/disable. A disabled policy is skipped during authorization but keeps its recorded usage, so re-enabling it with POST /policies/{id}/enable resumes from where it left off. Enabling an already-enabled policy, or disabling an already-disabled one, returns it unchanged.

Seeing what applies and what remains

GET /policies lists the policies you created. To see the full set actually in force for one card, cardholder, or your program - including the policies inherited from a higher scope - use List effective policies. This is also how you read how much of each limit is left. Pass the scope as query parameters: scopeType (CARD, USER, or PROJECT) plus, for CARD and USER, the scopeId. The response lists every active policy that applies, most specific first. Each spend or transaction count limit carries a usage object with the headroom remaining in the window and a resetsAt timestamp for when it rolls over; restrictions and per-transaction caps report usage: null. This is the endpoint behind a “how much can I still spend today?” view, and only active policies are returned. See List effective policies for the full request and response shape.

Control types

Every policy type and the configuration it takes.

Scopes

Where policies attach and how the effective set is resolved.

​What you can control

Restrictions

Limits

​How policies work

​When a policy declines a transaction

​Managing policies

​Editing a policy