--- title: "Change Card Controls" method: PUT path: "/cards/{cardId}/card-controls" tags: ["Card Controls"] --- # Change Card Controls `PUT /cards/{cardId}/card-controls` Updates card controls for a single card. If the card control does not exist, it will be created. If the card control exists, it will be updated with the given values. Thus when updating, you have to provide all the values for the card control you want to set. Missing or not provided values are deleted if they exist. ## Path parameters - `cardId` string, uuid, required ## Request body - object - `categories` object, nullable - `type` 'MCC' | 'CATEGORY', required — Type of the category control to use. `MCC` represents the merchant category code as defined by card networks, whereas `CATEGORY` is a Pliant internal grouping of transactions done with a credit card. Both values can be found in the response from the [transaction details endpoint](./get-transactions-detail-batch) or in our [guide section](/docs/card-controls-1). - `values` string[], required — Values for this category control which should be allowed or blocked. Can be either a list of `MCCs` or Pliant's payment categories. Both values can be found in the response from the [transaction details endpoint](./get-transactions-detail-batch) or in our [guide section](/docs/card-controls-1). - `restriction` 'ALLOWED' | 'BLOCKED', required - `merchants` object, nullable - `type` 'MATCH_TERM' | 'MID', required — Type of the merchant control to use. `MATCH_TERM` is the merchant name to match. Matching here works by checking if the provided term is part of a merchant name, the check is case insensitive. `MID` represents the merchant identifier as assigned by the card network. It can be found in the [transaction details response](./get-transactions-detail-batch). There it is named `mid`. - `values` string[], required — Values for this merchant control which should be allowed or blocked. - `restriction` 'ALLOWED' | 'BLOCKED', required - `dates` object, nullable - `type` 'YEARLY' | 'MONTHLY' | 'WEEKLY' | 'FIXED', required — Type of the date control to use. `YEARLY`, `MONTHLY` and `WEEKLY` are recurring dates, whereas `FIXED` is a fixed date range. - `values` string[], required — Values for this date control which should be allowed or blocked. The allowed patterns depending on the selected type are as follows: `YEARLY`: set of `dd.MM-dd.MM`. `MONTHLY`: set of `dd-dd` or alternatively `last`, `last-1` or `last-2` to specify the last day of the month or one to two days before. Allowed values are: `01-28`,`last-2`,`last-1` and `last`. `WEEKLY`: set of day of the week `MONDAY, TUESDAY, ... SUNDAY`. `FIXED`: set of `dd.MM.yyyy-dd.MM.yyyy`. So for example if you want to block all transactions at the end of the month, you can use `MONTHLY` with the value `20-last`. - `timezone` string, required — Timezone to use for the date control. A list of valid timezones can be found in our [guide section](/docs/card-controls-1). - `restriction` 'ALLOWED' | 'BLOCKED', required - `times` object, nullable - `type` 'TIMERANGE', required — Type of the time control. Currently only `TIMERANGE` is supported. - `values` string[], required — Only one time range is allowed for this control. The allowed pattern is `HH:mm-HH:mm`. So for example if you want to block all transactions between 10pm and 6am, you can use `TIMERANGE` with the value `22:00-06:00`. - `timezone` string, required — Timezone to use for the time control. A list of valid timezones can be found in our [guide section](/docs/card-controls-1). - `restriction` 'ALLOWED' | 'BLOCKED', required - `locations` object, nullable - `type` 'POSTAL_CODE' | 'REGION', required — Type of the location-based control. - `POSTAL_CODE`: Then `values` are postal codes - `REGION`: Then `values` are region IDs of your organization - `values` string[], required — Values for this location control which should be allowed or blocked. The allowed pattern is a list of postal codes or region IDs (depending on `type`). So for example if you want to block all transactions in the postal codes 12345 and 67890, you add both as values here with the restriction `BLOCKED`. Please note that the postal codes are case insensitive and may have different patterns depending on the country the credit card transaction was made in. Also not all credit card transactions carry a postal code, so this control might not be applicable to all transactions. We mitigate this by also consulting the postal code of the merchant used in the transaction. - `restriction` 'ALLOWED' | 'BLOCKED', required - `countries` object, nullable — Optional object defining country-based transaction restrictions. You can configure cards to either allow transactions only in specified countries (whitelist) or block transactions in specified countries (blacklist). Country codes must be valid ISO 3166-1 alpha-3 codes (e.g., `DEU`, `AUT`, `USA`). This control is not available for US-issued cards. - `restriction` 'ALLOWED' | 'BLOCKED', required — Defines the restriction type for the country control. - `ALLOWED`: Only transactions in the listed countries are permitted (whitelist). - `BLOCKED`: Transactions in the listed countries are declined (blacklist). - `values` string[], required — List of ISO 3166-1 alpha-3 country codes (e.g., `DEU`, `AUT`, `USA`). At least one country code must be provided. - `currencies` object, nullable — Optional object defining currency-based transaction restrictions. You can configure cards to either allow transactions only in specified currencies (whitelist) or block transactions in specified currencies (blacklist). Currency codes must be valid ISO 4217 codes (e.g., `EUR`, `GBP`, `USD`). - `restriction` 'ALLOWED' | 'BLOCKED', required — Defines the restriction type for the currency control. - `ALLOWED`: Only transactions in the listed currencies are permitted (whitelist). - `BLOCKED`: Transactions in the listed currencies are declined (blacklist). - `values` string[], required — List of ISO 4217 currency codes (e.g., `EUR`, `GBP`, `USD`). At least one currency code must be provided. - `acceptanceMethods` object, nullable — Optional object defining which acceptance methods are allowed for card transactions. If this object is provided, only the acceptance methods listed in `values` will be permitted — all others will be automatically blocked. - `type` 'ACCEPTANCE_METHOD', required — Type of the acceptance method control to use. Currently only `ACCEPTANCE_METHOD` is supported. - `values` string[], required — List of acceptance methods that are allowed for transactions. Only the methods listed here will be permitted if this control is provided. Possible values: - `ONLINE`: Card-not-present transactions - `MOBILE_WALLET`: Payments via mobile wallets (e.g., Apple Pay, Google Pay) - `MANUAL_ENTRY`: Card number entered manually - `CONTACTLESS`: Tap-based payments - `CHIP_DIP`: Inserted chip transactions - `NOT_AVAILABLE`: Transactions where acceptance method information is unavailable - `MAGNETIC_STRIPE`: Swipe-based payments - `OTHER`: Any other unspecified acceptance method - `restriction` 'ALLOWED', required — Defines the restriction type for the acceptance method control. Currently, only `ALLOWED` is supported — meaning only the specified methods are allowed. ## Response `202` Accepted ## Other responses - `400` — unresolved $ref - `401` — unresolved $ref - `403` — unresolved $ref - `404` — unresolved $ref - `500` — unresolved $ref --- [API](https://skmtc.dev/getpliant/apis/pliant-customer-api.md) · [All operations](https://skmtc.dev/getpliant/apis/pliant-customer-api/llms.txt) · [OpenAPI document](https://skmtc-service-production.skmtc.workers.dev/v1/apis/getpliant/pliant-customer-api/revisions/f3f589cfa718/schema)