Authorization configurations
The Authorization configurations API can be used to register configurations at the org, program, and account levels. The authorization configuration is retrieved based on the hierarchy Account > Program > Org.
If the configuration for the account is not found, the system looks for the configuration at the next higher level successively. If no configuration is found, the system continues with the standard Authorization flow.
Each of the endpoints and parameters are defined in the Authorization configurations API documentation, but the following table allows you to easily determine which parameters are required for Full balance and which are required for Zero balance.
| Field | Type | Description | Default value | Full balance | Zero balance |
|---|---|---|---|---|---|
approve_anti_fraud_unavailable | boolean | If set to true when anti-fraud is unavailable, the anti-fraud check is marked as APPROVED.If set to false, it is marked as REJECTED. | false | X | |
should_use_anti_fraud_decision | boolean | Flag indicates whether anti-fraud decisions should be used. | false | X | |
use_anti_fraud_response_code | boolean | Flag indicates whether we should use the response code sent in anti-fraud. | false | X | |
use_rates_fee_models | boolean | Flag indicates whether rate fee models should be used. | false | X | |
enabled_partial_authorization | boolean | By default, authorizations don’t validate partial authorization, but if this property is enabled, it allows the platform to process partial authorizations for a given org/program/account. NOTE: This property also depends on the merchant, as it is necessary for the merchant to be able to partially authorize. | false | X | X |
disable_dcc | boolean | This setting indicates whether or not the program allows dynamic currency conversion (DCC) transactions. By default, every program allows DCC transactions. In case it's necessary to block this type of transaction, you must set the configuration to true.NOTE: A transaction is considered as DCC when: -The merchant's country is different from the cardholder's country -The currency used in the transaction is the same as the cardholder's. For example, for a card issued in Brazil, in BRL currency (986): -A purchase in USD (840) in the US is not considered DCC -A purchase in BRL (986) in the US is considered DCC | false | X | X |
deny_all_authorizations | boolean | Flag indicates whether authorizations should be denied. This is useful for cases where a product is deprecated or during a migration process. | false | X | |
use_settlement_from_network | boolean | By default, in clearing flow for international purchases, the authorizations use the same settlement amount of authorization (online flow). If you set this flag to trueit means the system will use the settlement amount from the clearing message, which can be different from authorization. | false | X | |
call_anti_fraud_when_cancelling | boolean | Flag indicates whether the anti-fraud API should be called during cancellation. | false | X | |
days_to_cancel_pre_authorization | integer | Number of days to cancel pre-authorization. NOTE: the minimum number of days is 1 and the maximum is 60. | 35 | X | |
days_to_cancel_authorization | integer | Number of days to cancel authorization. NOTE: the minimum number of days is 1 and the maximum is 60. | 10 | X | |
days_to_cancel_pre_authorization_migration | integer | Number of days to cancel migrated pre-authorization. NOTE: the minimum number of days is 1 and the maximum is 60. | 35 | X | |
days_to_cancel_authorization_migration | integer | Number of days to cancel migrated pre-authorization. NOTE: the minimum number of days is 1 and the maximum is 60. | 10 | X | |
zero_balance_url | string | Indicates that it’s a Zero Balance flow, so the URL to call the customer’s service is informed. NOTE: This is only required for Zero balance. | X | ||
always_call_ledger_rules | boolean | Flag indicates whether Ledger API and Rules API should be always called, even when the authorization has already been denied. NOTE: When this flag is enabled, instead of skipping the Ledger validation due to a previous rejected validation, it will call the Dry Run endpoint from Ledger. The Dry Run endpoint does not impact the account balance/limits. It performs the same validations from the standard endpoint and then return the simulated account balance if the account was impacted. These informations are sent to the client’s Anti-Fraud service, where they can perform their own validations using this data. For example, after validating the Dry Run results, the client can force approve the authorization via Anti-Fraud. This way, the account balance will be impacted after the Anti-Fraud response. | false | X | X |
override_bins | object | This object may contain one or more of the above fields to be overridden individually at the BIN level, applying the default values if absent. For an example with override bins, refer to Run the configuration requests. NOTE: The BIN configuration currently only occurs for the deny_all_authorizations field. | X | X |
Updated about 2 hours ago
Related pages
To see code samples of how to run the basic configuration create (POST), read (GET), update (PUT), and delete requests, refer to: