--- title: "Create account flex control" method: POST path: "/v1/accounts/{accountId}/flex-controls" tags: ["Account flex controls"] --- # Create account flex control `POST /v1/accounts/{accountId}/flex-controls` Creates flex control for account. You use flex controls to restrict financial operations. For example, you can set spending and usage limits. For more information, refer to [Flexible transaction controls](https://developers.pismo.io/pismo-docs/docs/flex-controls). To create a cumulative condition, the `type` can be: - `spending_limit` to restrict the maximum total amount that can be transacted during an specific period. - `usage_limit` to evaluate the quantity of transactions. The cumulative control type must also specify the `max_limit`. The `limit_duration` and `reset_period` parameters are optional, but they are linked with the behavior of `max_limit`. To create a restriction condition, set `type` as `restriction`. To restrict an operation, the restriction control must specify: - at least one condition in the `conditions` array. - the required values for `attribute`, `operator`, and `value` in the condition. Once you create the control, you can't change its type. This endpoint generates an [Account flex control created](https://developers.pismo.io/events/docs/audit-account-spending-limit-created-1) event. NOTE: This endpoint requires an account-specific access token. ## Path parameters - `accountId` number, required ## Request body - CreateAccountFlexControlRequest — Creates new flex control for account. - `type` 'authentication' | 'challenge-request', required — Evaluation intention - `processing_codes` ProcessingCodes — Object with the processing codes for credit and debit operations - `credit` string — Processing code that identifies the credit operation - `debit` string — Processing code that identifies the debit operation - `name` string, required — name - `beneficiary_id` string — Account beneficiary ID - `override_controls` string[] — List of existing flex control IDs to override. The platform ignores these controls and only evaluates the new flex control. - `currency_code` string — ISO 4217 3-letter currency code, For example, `986` = Brazilian real and `840` = US dollar. - `time_zone` string — IANA Time Zone database, such as "America/New_York". This attribute is used to evaluate the flex control using the desired time zone for condition attributes such as `week_day`, `month_day`, `time_now`, and `reset_period`. If `time_zone` is empty, the control is evaluated using the UTC time zone. - `max_limit` integer — Maximum spending limit. Once met or exceeded, any subsequent transactions are declined by evaluation control flow. Note that this value is an integer. Since global currencies vary in the number of digits that are allowed after the decimal point, you must convert the actual maximum spending limit into an integer value to use in this field. To do this, use the following formula. value = floatNumber × 10^X, where X is the number of digits after the decimal separator for the currency as defined in ISO 4217. For example, if you want to set the value 499.99 for BRL currency transactions, where the number of decimal places is 2, you must set it to `49999` (499.99 × 10²). If you want to set the value 499 for JPY currency transactions, where the number of decimal places is 0, you must set it to `4999` (4999.0 × 10^0 = 4999.0 × 1 - in other words, the value doesn't change.) This field is **REQUIRED** for cumulative controls. - `limit_duration` string — Flex control limit period duration (ISO 8601 format). For example, if a flex control sets a spending limit of $500, and `limit_duration` is set to one month (`P1M`), then the user cannot spend more than $500 from the account in any one month period. If `limit_duration` is not set, then the flex control does not accumulate. - `reset_datetime` string, date-time — *Note: This field has been deprecated. The field `reset_period` has replaced `reset_datetime`.* The reset datetime (RFC-3339 format) of the flex control. - `reset_period` ResetPeriod — Enables the specification of reset periods for accumulators based on the duration in `limit_duration`. When this field is set, it must follow the RFC 3339 pattern from ISO 8601. When `reset_period` changes, the `avaliable_limit` is reset. - `month_day` number — Month day to reset. Can only be used when `limit_duration` is monthly. - `month` number — Numeric day of the month to reset the flex control. Can only be used when `limit_duration` is yearly. - `week_day` 'monday' | 'tuesday' | 'wednesday' | 'thursday' | 'friday' | 'saturday' | 'sunday' — Week day to reset. Can only be used when `limit_duration` is weekly. - `time` string — Time to reset flex control in time zone defined by control. Include only hours, minutes, and AM/PM. For example, `11:00PM` for 11PM or `00:00AM` for midnight. You can use `12` in hours as an alternative to `00` (for example,`12:59AM` is the same as `00:59AM`). - `utc_time` string — *Note: This field has been deprecated, use `time` instead.* Time to reset the flex control in the UTC 0 time. Include only hours, minutes, and AM/PM. For example, `11:00PM` for 11PM or `00:00AM` for midnight. You can use `12` in hours as an alternative to `00` (for example,`12:59AM` is the same as `00:59AM`). - `conditions` Condition[] - `type` 'INSTALLMENT_NUMBER' | 'PROCESSING_CODE' | 'ACCOUNT_TYPE' | 'ORIGIN' | 'DCC' | 'DOMESTIC' | 'MERCHANT_NAME_LIST' | 'INSTALLMENT_PLAN' | 'AMOUNT' | 'MERCHANT_CATEGORY_CODE' | 'REVERSAL_INDICATOR' | 'AUTHORIZATION_FLOW' | 'ORIGINAL_PROCESSING_CODE' | 'MTI', required — List types and data formats allowed: - `INSTALLMENT_NUMBER` - Integer values - `PROCESSING_CODE` - Alphanumeric strings - `ACCOUNT_TYPE` - Alphanumeric strings - `ORIGIN`- Alphanumeric strings - `DCC`- Boolean values - `DOMESTIC`- Boolean values - `MERCHANT_NAME_LIST` - Alphanumeric strings - `INSTALLMENT_PLAN` - Alphanumeric strings - `AMOUNT` - Numbers with or without decimal places - `MERCHANT_CATEGORY_CODE` - Alphanumeric strings - `REVERSAL_INDICATOR` - Boolean values - `AUTHORIZATION_FLOW` - Either `PAYMENTS` or `NETWORK` - `ORIGINAL_PROCESSING_CODE`- Original processing code or persisted authorization processing code - `MTI` - Message Type Indicator (MTI) - a four-digit numeric field - ISO 8583 standard - `operator` 'eq' | 'neq' | 'gt' | 'gte' | 'lt' | 'lte' | 'in' | 'contains' | 'starts_with' | 'ends_with', required — Operator that will be used on this rule evaluation - `eq`: Equals operator, allowed with rules that evaluate data containing strings, numbers, and booleans. - `neq`: Not equals operator, allowed with rules that evaluate data containing strings, numbers, and booleans. - `gt`: Greater than operator, allowed with rules that evaluate data containing numbers. - `gte`: Greater than or equal operator, allowed with rules that evaluate data containing numbers. - `lt`: Less than operator, allowed with rules that evaluate data containing numbers. - `lte`: Less than or equal operator, allowed with rules that evaluate data containing numbers. - `in`: In operator, allowed with rules that use model list as data. Compares if the data is in the configured list. - `contains`: Contains operator, allowed with rules that use model list as data. Compares if the data is part of any string in the configured list. - `starts_with`: Starts with operator, allowed with rules that use model list as data. Verifies whether any string in the list starts with the data value. - `ends_with`: Ends with operator, allowed with rules that use model list as data. Verifies whether any string in the list ends with the data value. - `data` string, required — Data used to evaluate this rule against the operator and the information received in the request. This field must be in the format as indicated in `type` and `operator`. **Note:** This field's value can be a model list ID returned from [Create model list](https://developers.pismo.io/pismo-docs/reference/post-org-model-list). A model list contains a list of values for evaluation. - `deny_code` string, required — Deny code related to restriction. This code is returned when the evaluation does not meet the conditions. - `response_code` string — Network two-digit response code. For example: 00 = approve, 51 = insufficient funds, 57 = card not active, 96 = system failure, etc. For more information, see [Validation codes for authorization events](https://developers.pismo.io/pismo-docs/docs/validation-codes-for-authorization-events). If `approve` = `false`, you can use this value to respond to the network. - `custom_code` 'FL2' | 'FL8' | 'FLB' | 'FLE' | 'DCM' | 'VMN' | '998' | 'LUD' | 'LUE' | 'LUT' | 'LGE' | '810' | 'PFT' | 'IAT' | 'BND' | 'ANF' | 'CTE' | 'CED' | 'ZBD' | 'FRB' | 'UBT' | 'FL6' | 'BNF' | 'BNP' | 'BNR' | 'VED' | 'BNU' | 'VEV' | 'UBN' | 'CSU' | 'NPL' | 'OP1' | 'TNF' | 'Z26' | 'Z24' | 'Z29' | 'Z23' | 'Z22' — Internal custom code generated in authorization flow for declined requests, indicating the reason the request was declined. For more information, see [authorization validations](https://developers.pismo.io/pismo-docs/docs/validation-codes-for-authorization-events#authorization-validations). - `evaluation_order` integer — Order in which the control is evaluated. If this value is not provided, the control is evaluated after the controls with the configured `evaluation_order` value. - `active` boolean — Is the program calendar strategy active? ## Response `201` OK. Successful flex control creation. - AccountFlexControlsResponse — Flex control response. - `id` string, uuidv4, required — Flex control ID - `deny_code` string, required — Deny code related to restriction. This code is returned when the evaluation does not meet the conditions. - `name` string, required — name - `type` 'authentication' | 'challenge-request', required — Evaluation intention - `rule_reference_id` string — Flex control template ID - `beneficiary_id` string — Account beneficiary ID - `override_controls` string[] — List of existing flex control IDs to override. The platform ignores these controls and only evaluates the new flex control. - `description` string — Flex control description - `processing_codes` ProcessingCodes — Object with the processing codes for credit and debit operations - `credit` string — Processing code that identifies the credit operation - `debit` string — Processing code that identifies the debit operation - `currency_code` string — ISO 4217 3-letter currency code, For example, `986` = Brazilian real and `840` = US dollar. - `time_zone` string — IANA Time Zone database, such as "America/New_York". This attribute is used to evaluate the flex control using the desired time zone for condition attributes such as `week_day`, `month_day`, `time_now`, and `reset_period`. If `time_zone` is empty, the control is evaluated using the UTC time zone. - `max_limit` integer — Maximum spending limit. Once met or exceeded, any subsequent transactions are declined by evaluation control flow. Note that this value is an integer. Since global currencies vary in the number of digits that are allowed after the decimal point, you must convert the actual maximum spending limit into an integer value to use in this field. To do this, use the following formula. value = floatNumber × 10^X, where X is the number of digits after the decimal separator for the currency as defined in ISO 4217. For example, if you want to set the value 499.99 for BRL currency transactions, where the number of decimal places is 2, you must set it to `49999` (499.99 × 10²). If you want to set the value 499 for JPY currency transactions, where the number of decimal places is 0, you must set it to `4999` (4999.0 × 10^0 = 4999.0 × 1 - in other words, the value doesn't change.) This field is **REQUIRED** for cumulative controls. - `available_limit` integer — Total available limit to spend, calculated by: max_limit - current_spend_limit. The `current_spend_limit`, an internal field, is the total amount of all approved transactions in the `limit_duration` period. It is reset by the evaluation flow when a new transaction is evaluated in the new period according to the `reset_datetime`. When `available_limit` is set in a PATCH request, it resets `current_spend_limit`. In this case, `available_limit` cannot be greater than `max_limit`. Note that `available_limit` is an integer. Since global currencies vary in the number of digits that are allowed after the decimal point, you must convert the actual maximum spending limit into an integer value to use in this field. To do this, use the following formula: value = floatNumber * 10^x, where x is the number of digits for the currency as defined in ISO 4217. For example, if you want to set the value 499.99 for BRL currency transactions, you must set 49999 = 499.99 * 10^2. On the other hand, the Japanese money system does't use fractions of a yen (the Japanese currency). So, to set the value at 4999 yen, you must set 4999 = 4999.0 * 10^0 = 4999.0 * 1. (In other words, the value doesn't change.) - `conditions` Condition[] - `type` 'INSTALLMENT_NUMBER' | 'PROCESSING_CODE' | 'ACCOUNT_TYPE' | 'ORIGIN' | 'DCC' | 'DOMESTIC' | 'MERCHANT_NAME_LIST' | 'INSTALLMENT_PLAN' | 'AMOUNT' | 'MERCHANT_CATEGORY_CODE' | 'REVERSAL_INDICATOR' | 'AUTHORIZATION_FLOW' | 'ORIGINAL_PROCESSING_CODE' | 'MTI', required — List types and data formats allowed: - `INSTALLMENT_NUMBER` - Integer values - `PROCESSING_CODE` - Alphanumeric strings - `ACCOUNT_TYPE` - Alphanumeric strings - `ORIGIN`- Alphanumeric strings - `DCC`- Boolean values - `DOMESTIC`- Boolean values - `MERCHANT_NAME_LIST` - Alphanumeric strings - `INSTALLMENT_PLAN` - Alphanumeric strings - `AMOUNT` - Numbers with or without decimal places - `MERCHANT_CATEGORY_CODE` - Alphanumeric strings - `REVERSAL_INDICATOR` - Boolean values - `AUTHORIZATION_FLOW` - Either `PAYMENTS` or `NETWORK` - `ORIGINAL_PROCESSING_CODE`- Original processing code or persisted authorization processing code - `MTI` - Message Type Indicator (MTI) - a four-digit numeric field - ISO 8583 standard - `operator` 'eq' | 'neq' | 'gt' | 'gte' | 'lt' | 'lte' | 'in' | 'contains' | 'starts_with' | 'ends_with', required — Operator that will be used on this rule evaluation - `eq`: Equals operator, allowed with rules that evaluate data containing strings, numbers, and booleans. - `neq`: Not equals operator, allowed with rules that evaluate data containing strings, numbers, and booleans. - `gt`: Greater than operator, allowed with rules that evaluate data containing numbers. - `gte`: Greater than or equal operator, allowed with rules that evaluate data containing numbers. - `lt`: Less than operator, allowed with rules that evaluate data containing numbers. - `lte`: Less than or equal operator, allowed with rules that evaluate data containing numbers. - `in`: In operator, allowed with rules that use model list as data. Compares if the data is in the configured list. - `contains`: Contains operator, allowed with rules that use model list as data. Compares if the data is part of any string in the configured list. - `starts_with`: Starts with operator, allowed with rules that use model list as data. Verifies whether any string in the list starts with the data value. - `ends_with`: Ends with operator, allowed with rules that use model list as data. Verifies whether any string in the list ends with the data value. - `data` string, required — Data used to evaluate this rule against the operator and the information received in the request. This field must be in the format as indicated in `type` and `operator`. **Note:** This field's value can be a model list ID returned from [Create model list](https://developers.pismo.io/pismo-docs/reference/post-org-model-list). A model list contains a list of values for evaluation. - `limit_duration` string — Flex control limit period duration (ISO 8601 format). For example, if a flex control sets a spending limit of $500, and `limit_duration` is set to one month (`P1M`), then the user cannot spend more than $500 from the account in any one month period. If `limit_duration` is not set, then the flex control does not accumulate. - `reset_period` ResetPeriod — Enables the specification of reset periods for accumulators based on the duration in `limit_duration`. When this field is set, it must follow the RFC 3339 pattern from ISO 8601. When `reset_period` changes, the `avaliable_limit` is reset. - `month_day` number — Month day to reset. Can only be used when `limit_duration` is monthly. - `month` number — Numeric day of the month to reset the flex control. Can only be used when `limit_duration` is yearly. - `week_day` 'monday' | 'tuesday' | 'wednesday' | 'thursday' | 'friday' | 'saturday' | 'sunday' — Week day to reset. Can only be used when `limit_duration` is weekly. - `time` string — Time to reset flex control in time zone defined by control. Include only hours, minutes, and AM/PM. For example, `11:00PM` for 11PM or `00:00AM` for midnight. You can use `12` in hours as an alternative to `00` (for example,`12:59AM` is the same as `00:59AM`). - `utc_time` string — *Note: This field has been deprecated, use `time` instead.* Time to reset the flex control in the UTC 0 time. Include only hours, minutes, and AM/PM. For example, `11:00PM` for 11PM or `00:00AM` for midnight. You can use `12` in hours as an alternative to `00` (for example,`12:59AM` is the same as `00:59AM`). - `reset_datetime` string, date-time — Reset datetime (RFC-3339 format) for the control rule. If `reset_datetime` is not set, a default is calculated based on `limit_duration` period and the current time. This field should only be specified when `type` is either `spending_limit` or `usage_limit`. - `active` boolean — Is the program calendar strategy active? - `customized` boolean — Indicates whether the flex control is managed by the user. If `customized` is `false`, the flex control is managed by the card's program. Generally speaking, users shouldn't change flex controls created by the program, however it is possible to do so. You can reverse indivdually managing a flex control with a call to [Update account flex control](https://developers.pismo.io/pismo-docs/reference/patch-v1-accounts-flex-control) or [Update customer flex control](https://developers.pismo.io/pismo-docs/reference/patch-v1-customers-flex-control) and setting `customized` as `false`. - `response_code` string — Network two-digit response code. For example: 00 = approve, 51 = insufficient funds, 57 = card not active, 96 = system failure, etc. For more information, see [Validation codes for authorization events](https://developers.pismo.io/pismo-docs/docs/validation-codes-for-authorization-events). If `approve` = `false`, you can use this value to respond to the network. - `custom_code` 'FL2' | 'FL8' | 'FLB' | 'FLE' | 'DCM' | 'VMN' | '998' | 'LUD' | 'LUE' | 'LUT' | 'LGE' | '810' | 'PFT' | 'IAT' | 'BND' | 'ANF' | 'CTE' | 'CED' | 'ZBD' | 'FRB' | 'UBT' | 'FL6' | 'BNF' | 'BNP' | 'BNR' | 'VED' | 'BNU' | 'VEV' | 'UBN' | 'CSU' | 'NPL' | 'OP1' | 'TNF' | 'Z26' | 'Z24' | 'Z29' | 'Z23' | 'Z22' — Internal custom code generated in authorization flow for declined requests, indicating the reason the request was declined. For more information, see [authorization validations](https://developers.pismo.io/pismo-docs/docs/validation-codes-for-authorization-events#authorization-validations). - `evaluation_order` integer — Order in which the control is evaluated. If this value is not provided, the control is evaluated after the controls with the configured `evaluation_order` value. ## Other responses - `400` — Bad request. Validation error on request. - `403` — Forbidden. Authorization error on request. - `409` — Conflict. - `500` — Internal server error. --- [API](https://skmtc.net/pismo/apis/platform-authentication.md) · [All operations](https://skmtc.net/pismo/apis/platform-authentication/llms.txt) · [OpenAPI document](https://skmtc-service-staging.skmtc.workers.dev/v1/apis/pismo/platform-authentication/versions/935b62e16de4/schema)