Operation limits

Cap what a card may do per transaction, per day, per week and per month, by channel and operation type.

Operations24DomainLimits and controlsStatedocumentedAPIs3

How this behaves

An operation limit is keyed by five things at once

This is a different layer from the card and customer limits. Those say how much; these say where, how and how often — and they live in their own table with their own operations.

The key of one row
  1. Transaction groupPurchase, cash, transfer…
  2. Main groupIts parent band
  3. ChannelPOS, ATM, internet, mobile
  4. NetworkDomestic / international
  5. EventWhat triggered it

At customer level the key is wider still: the merchant category and its group join it, a limit profile detail can be named, and the periods run per transaction, daily, weekly, monthly and yearly.

One call, many rows, and each one answers for itself

Why 200 is not the answer
setCardOperationLimitMany rows in one request
  • AppliedInsert, update or deleteDecided per row
  • Refused — flagCustomisation is closed for that key in the parameter
  • Refused — profileThe profile code sent does not match the card's
  • DeletedEvery amount and count left emptyNot “leave unchanged”
Read the result list, not the status code.

A 200 means the call ran. Each row carries its own outcome, and at customer level each one also names what happened to it — insert, update or delete — so the caller learns the effect rather than being told its own request back.

  • A dry run is supported. With the validation-only flag set, every check runs, nothing is written, and the result list still comes back — which is what a "show me before I save" screen needs.
  • The description fields beside the key are not carried. They are absent from the integration's own mapping, so sending them changes nothing.

Operations

credit-digital-channels-integration

debit-digital-channels-integration

prepaid-digital-channels-integration