Requisite Selection

Stage 1. Trader selection in Core

Filters run in this order, and a trader has to clear all of them:

1. ID — the trader is in the list of the merchant’s gateway settings.

2. Method — the requested requisite type is enabled for the trader.

3. Direction — the trader is not locked for pay / payout traffic.

4. Currency — default_currency, the currency the trader was created with, matches the request currency.

5. Balance — for payin, the main wallet covers the amount.

6. Maximum — amount < max_limit; 0 or no record disables the limit.

7. Minimum — amount > min_limit; 0 or no record disables the limit.

The general limits are strict on both ends: with min_limit of 21 an amount of exactly 21 is rejected, and with max_limit of 21 so is exactly 21.

Traders that fail a filter are skipped, not fatal: with several traders in list, one without balance or without a matching requisite simply hands the payment to the next one.

Stage 2. Requisite selection in Trader

After the first pass in Core, the list of traders is handed to the Trader service, where it goes through a second pass.

A candidate requisite must satisfy every condition:

1. The bank profile is not blocked.

2. The device the profile is bound to has the active status.

3. The requisite has the active status.

4. The requisite type matches the requested one.

5. min_amount <= amount.

6. amount <= max_amount, unless max_amount is 0.

7. The unfinished operation count is below the concurrent limit.

8. Today’s used amount plus this amount stays within the daily amount limit.

9. Today’s operation count is below the daily transaction limit.

10. bank_name matches the profile’s bank when the request supplies one.

Devices are then excluded whole when they already hold a pending operation of the same amount and method — this is what the amount randomizer works around. One requisite is picked from what remains, weighted by conversion.

Amount uniqueness per device

A device can hold only one requisite issued for a given amount within a single requisite type at a time. In other words, this constraint always holds: unique (amount, device_id, requisite_type) where status = pending and source = trader