Server-side spend controls are centralized rules enforced by a card issuer or program manager that determine whether a corporate card transaction is approved, declined, or routed for review. Unlike client-side settings that rely on an end user’s device or app state, server-side controls are applied in real time during authorization, using data such as merchant category codes (MCC), transaction amount, currency, location, time, and cardholder identity. These controls are commonly used to reduce fraud exposure, standardize policy compliance, and align day-to-day purchasing with departmental budgets.
When a card is presented, the merchant sends an authorization request through the card network to the issuer. Server-side control logic evaluates the request against configured policies (for example, per-transaction limits, daily caps, or prohibited MCCs) and returns an approval or decline response within the network’s required time window. Controls can also incorporate velocity checks (frequency of transactions), exception lists (allowed merchants or countries), and step-up workflows such as requiring managerial approval before subsequent charges are permitted.
Typical server-side controls include amount limits (single purchase, daily, weekly, monthly), category controls (blocking or allowing specific MCCs such as travel, entertainment, or gambling), geographic restrictions (country/region allowlists and blocklists), and channel restrictions (card-present vs. e-commerce, contactless, or recurring billing). More advanced programs add merchant allowlists, time-of-day rules, and card state restrictions such as freezing or temporarily disabling a card. Controls are often complemented by automated alerts and audit logs to support internal controls and external reporting requirements.
In corporate card programs, spend controls are usually tied to organizational structures such as cost centers, projects, or subsidiaries, enabling policy inheritance and delegated administration. Auditability is supported through immutable logs of configuration changes and decision outcomes (approve/decline reasons), which can be reconciled with expense systems and general ledger mappings. Some platforms also link controls to treasury workflows so that approved spend aligns with available balances and settlement processes; in stablecoin-based card stacks, this may include authorization decisions that account for conversion, settlement timing, and funding source selection, as seen in products such as Oobit.