Authorization Rules
Authorization is a transaction that requires two processes to complete, an initial one and another to confirm or reverse the first. As with execution, accounting mapping of all financial passages is necessary both in authorization and confirmation. Reversal is automatically mapped to undoing authorization.
With each call for authorization and its confirmation or reversal, a transactional ID is generated and the relationship between these transactions is recorded in the final transaction in the parent_id property. This way, an authorization will always generate two transaction IDs at the end.
In each authorization process, in a unique and atomic way, one or more financial entries (double-entries in debit and credit) will be created and return the ID of the created transaction.
The rules for authorization determine the accounting mapping of each entry involved and its order of execution, control of the balance of each part and which accounts will be received as an input parameter at the time of its creation, with up to two accounts permitted.
The rules for authorization are globally controlled by transaction type, which are terms freely chosen by the user.
Processes
The two authorization processes must be mapped - the authorization itself and its confirmation. Each process must have its own list of entries mapped.
Entries
The entries are the debits and credits that will be executed atomically in the transaction and must have their accounting functioning mapped.
Entry types
The entry types are terms freely chosen by the user, except for the main_amount type, which refers to the main value informed when creating the transaction. The main_amount type is usually mapped as the first in a list of entries, but is not mandatory if the execution receives the value zero during its creation.
Entry order
Each entry receives a number to order its sequential execution as determined by the user. Entries are carried out in this order, first debits and then credits.
Source of accounts
For both debits and credits, the source of the account involved must be specified. This can be one of the accounts mapped and created as unique in the system (unique_account) or originating from one of the accounts that were informed in the transaction input parameters (param_account_1 or param_account_2).
Accounts descriptions
For both debits and credits, the description of the account involved must be specified. The description must exist in the account rules record.
Balance type
For both debits and credits, you must specify the type of balance to be moved. The balance type must exist, for that account description, in the account rules record. The permitted types are available, pending and blocked.
Balance validation
For both debits and credits, you must specify what type of balance validation will be carried out. The allowed validations are:
positive
the system will not allow the desired balance to become negative
negative
the system will not allow the desired balance to become positive
no_validation
the system will not validate the desired balance
Create or Update an Authorization Rule
The PUT /authorization_rules method is used to create or update an authorization rule individually or in batch, based on the transaction_type field.
Example of creating/updating rules:
Delete of an Authorization Rule
The DELETE /authorization_rules method is used do delete an authorization rule individually.
Example of deleting rules:
Authorization Rules query
The GET /authorization_rules method is used to query the rules.
Rules query example:
Example response:
Last updated