# Spend Controls
source: https://developer.mastercard.com/business-payment-controls/documentation/use-cases/spend-controls/index.md

Spend Control rules are a set of user-defined authorization controls that Mastercard Business Payment Controls performs on authorization data. A rule can contain one or more spend controls. A real card or virtual card can have one or more rules applied.

Setting a rule restricts a card's behavior by applying controls to approve or decline the authorization, or to alert the user that an authorization has occurred. The order of evaluation depends on the control order within the rule.
Note: An update of any control on an existing card should include the full set of existing controls to be re-submitted. For this reason, we recommend completing a GET call on an existing card in advance of an update being made in order to determine any existing limits and balances, so that any desired updates are applied as intended.

### Business Payment Controls API spend controls {#business-payment-controls-api-spend-controls}

The following list compares spend controls available for rules:

### [AccountControl rules](https://developer.mastercard.com/business-payment-controls/documentation/use-cases/spend-controls/accountcontrol-spend-controls/index.md) {#accountcontrol-rulesdocumentationuse-casesspend-controlsaccountcontrol-spend-controls}

* An account can have one AccountControl rule
* An AccountControl rule can have *one* of each of the following controls:
  * Number of transactions (overall and by time)
  * Amount (overall and by time)
  * Country
  * Merchant category codes
  * Validity period
* Controls are tightly validated

### [inControl rules](https://developer.mastercard.com/business-payment-controls/documentation/use-cases/spend-controls/incontrol-spend-controls/index.md) ^[1](https://developer.mastercard.com/business-payment-controls/documentation/use-cases/spend-controls/index.md#fn:1)^ {#fnref:1}

* An account has only one inControl rule-set
* A rule-set may have multiple rules
* Each rule can have any combination of controls
  * Number of transactions
  * Countries
  * Velocities
  * Validity Period
  * Amount Ranges
  * Merchant Category Codes
  * Ageing Velocities
  * Curfews
  * Time Of Day
  * Merchant IDs
  * Merchant name
  * Transaction environment
  * Data entry mode
* Controls can be negated
* Controls are not validated

*** ** * ** ***

1. Replaces Mastercard In Control Retail API controls [↩︎](https://developer.mastercard.com/business-payment-controls/documentation/use-cases/spend-controls/index.md#fnref:1)

   {#fn:1}
{#fn:1}

### Funding source endpoints for spend controls {#funding-source-endpoints-for-spend-controls}


API Reference: `POST /funding-sources/{funding_source_guid}/controls`


API Reference: `PUT /funding-sources/{funding_source_guid}/controls`


API Reference: `DELETE /funding-sources/{funding_source_guid}/controls`


API Reference: `GET /funding-sources/{funding_source_guid}/controls`

<br />

## How spend control rules are evaluated and applied {#how-spend-control-rules-are-evaluated-and-applied}

Tip: When setting controls, the recommended approach is to:

1. Set the necessary controls to achieve a business result.
2. Do not set duplicate or opposing controls.
3. Test the control combinations that will be used to ensure they meet the business need.

Spend control rules can `Approve` or `Decline` when authorization occurs.

* Rules are evaluated using logical *OR*.
* Controls within each rule are evaluated using logical *AND*.

<!-- -->

* If a transaction has a match for an `Approve` rule, the transaction is approved. If the `Approve` rule has no match, the approval is declined.
* If a transaction has a match for a `Decline` rule, the transaction is declined.