Limits

General trader limits

min_limit and max_limit belong to the trader and are the only limits Core applies.

• amount must be strictly greater than min_limit;
• amount must be strictly lower than max_limit;
• 0, or no record at all, disables that boundary.

Requisite amount range

min_amount and max_amount belong to the requisite and, unlike the general limits, include their boundaries.

• min_amount <= amount;
• amount <= max_amount;
• max_amount == 0 means no upper boundary.

With min_amount of 221.00 an amount of 220.00 is rejected while 221.00 is accepted; with max_amount of 221.00 the amount 221.00 is still accepted and 222.00 is not.

Concurrent operations

When concurrent_transactions_enabled is on, the number of unfinished payins on the requisite must be lower than concurrent_transactions. Finalizing an operation frees a slot immediately.

Daily limits

Daily usage is counted per requisite.

Field	Purpose
transaction_limit	maximum number of operations per day
amount_limit	maximum total amount per day
transaction_delay	pause after each operation, in minutes
deactivate_limit_reached	enables the limit checks and the blocking
deactivate_dispute_present	blocks the requisite while it has an open dispute

An operation counts towards the daily figures as soon as it is assigned, and the amount limit is checked before the requisite is returned, so a payment that would push the total over the limit is rejected rather than issued. The requisite is blocked once the count or the amount limit is reached.

transaction_delay blocks the requisite after every operation and lets it back in a minute at a time — a blocked requisite is that setting’s normal resting state. It never clears a block set by the idle-requisite conversion check.

When an operation is declined, the used values are given back. If the result is below the limits, the requisite is reactivated immediately, or after transaction_delay when one is set.

All of these checks require deactivate_limit_reached to be enabled on the requisite.