This service allows you to authorize transactions.
There are two possibilities for the state of transactions created:
APPROVED: If the transaction is approved.
REJETED: If the transaction is rejected.
All transactions that are approved modify the account balance by the amount specified.
All transaction sums are given in the account’s currency with a positive sign. To determine whether the transaction is to deposit or withdraw money from an account, the entry_type parameter must be used. This parameter may be filled out as follows:
DEBIT: for transactions withdrawing money from the account.
CREDIT: for transactions depositing money into the account.
All transactions have a type, indicated with the type parameter. Each type has different data sent along with the transaction in the tx_properties object.
You can request extra data from all transactions using the metadata object.
details property may be used to break down the total transaction sum into its constituent parts. For example, suppose you are processing a transaction in a digital store totaling $149.99. Let us further suppose that this total is composed of:
This breakdown may be reported by adding multiple items to the details list. Each detail must have a type associated with it:
BASE: transaction base expense.
FEE: commission expenses.
EXTRACASH: money withdrawals.
More than one detail may be added with the same type. The only restriction is that the details total is equal to the transaction total.
Each transaction has a process_type field that can take any of these values:
ORIGINAL: New transaction.
REFUND: refund or return.
ADJUSTMENT transactions that are or can specify the original transaction they are based on. This transaction is known as a “parent transaction“, indicated by the
Transaction authorization requests have an idempotency mechanism to prevent duplicate processing.
For the transaction to be processed you must accompany each authorization request with an
X-Idempotency-Key header that has a unique identifier. If you do not get a response or receive one with status code type 5xx, repeat the request with the same idempotency key until you get a successful response (code 201).
Repeated requests using the same idempotency key will only result in a transaction being created. The first request creates the transaction and the next one gives the same response but does not create a new transaction.
If an authorization request has an idempotency key already used in another transaction, an error is returned.
Correctly processed transactions are reported with a status code 201. This status does not indicate whether the transaction was approved or not. Read the answer 'result' field and note if it is
Any other status code indicates that something went wrong and the reason for rejection is given in the rejection_reason field. This field may be filled out as follows:
INSUFFICIENT_FUNDS: The account does not have sufficient funds.
ACCOUNT_DISABLED: the account has been disabled.
ACCOUNT_FROZEN: The account cannot process debit transactions.
CLIENT_MONTHLY_AMOUNT_LIMIT_REACHED: exceeded the monthly movement limit it had.
CLIENT_DAILY_AMOUNT_LIMIT_REACHED: exceeded the limit of daily movements it had.
BRIDGE_ACCOUNT_MONTHLY_AMOUNT_LIMIT_REACHED: Exceeded the limit of monthly movements they had for bridge account.
BRIDGE_ACCOUNT_DAILY_AMOUNT_LIMIT_REACHED: Exceeded the limit of daily movements they had for bridge account.
PROCESS_TIME_EXPIRED: The transaction did not start processing before the time indicated in the process_before field, which is optional.
When a transaction cannot be processed an error response is returned with the error_code field indicating the reason:
ACCOUNT_NOT_FOUND: account could not be found.
INVALID_AUTHORIZATION_REQUEST: The transaction authorization request is not valid.
INVALID_PARENT_TX_ID: The parent transaction specified is invalid.
DUPLICATED_IDEMPOTENCY_KEY: You already used the idempotency key in another transaction.