Payment Queues
Access Prerequisites
- Permission (module):
processPaymentQueue(controls buttons in the UI) +manageToken(required by the backend for queue routes) - License/Feature: None specific.
- Menu container: GENERAL → group Charges (route
/manage-payment-queues)
What it is / when to use
Payment Queues model structures for NFT redemption/buyback by priority — typical of debts with a payment order, such as court-ordered payments (precatórios), public debts (TCU/União), debentures, or tokenized corporate obligations. Each queue is a rule: it selects which NFTs are included (by collection + attribute + attribute value), defines the payment priority, and the type (lump-sum or installment).
This screen handles queue configuration. The item-by-item execution (each NFT to be paid, in priority order) takes place on the Payment queue orders screen, where the operator approves the payment for each NFT: the system pays the holder the price_paid of the NFT from the platform wallet and returns the NFT to TKN_OWNER.
Prerequisites
- Permission:
processPaymentQueueregistered to enable buttons in the UI (dual permission — CPM enum + dynamic module in DB). The creation/editing/deletion routes are validated at the API-Gateway withmanageToken; without this enum the operation returns an error even when the button is visible. - License/Feature: None specific.
- Dependencies on other screens: the collection and the attribute/value referenced must exist in the issued NFTs — that is how the system knows which NFTs belong to the queue.
Step by step
- Go to Charges → Payment Queues (route
/manage-payment-queues). - The list shows queues with Name and Priority.
- Click Create new to open the configuration modal.
- Fill in Name, Collection, Priority, Attribute, Attribute value, and the Payment type.
- If the type is Installment, provide Percentage and Months.
- Confirm with Save. To edit, use the pencil icon; to remove, the trash icon.
Fields (queue modal)
| Field | What it is | Required? | System/backend effect |
|---|---|---|---|
| Name | Queue identifier | Yes | Saves name in payment_queue (TokenController). Locked on edit (cannot be changed after creation). |
| Collection | ID of the NFT collection served by the queue | Yes | Saves collectionId. Together with attribute/value, delimits the universe of eligible NFTs. |
| Priority | Precedence order of the queue in payment | Yes | Saves priority (numeric). Defines which queue/NFT is paid first when ordering the queue orders. Accepts numbers only. |
| Attribute | Name of the characteristic that marks an NFT as part of the queue | Yes | Saves attribute. Matched with Attribute value to select the NFTs. |
| Attribute value | Expected value of the attribute above | Yes | Saves value. E.g.: attribute tipo with value precatorio. |
| Payment type | Lump-sum (Upfront / A) or Installment / P | Yes | Saves payment_type (A or P). Switching to A clears percentage and months. Defines whether the NFT value is paid all at once or in portions. |
| Percentage | (Installment) % of the value paid per installment | Conditional (type P) | Saves percentage. Defines the size of each installment relative to the NFT value. |
| Months | (Installment) number/interval of installments | Conditional (type P) | Saves months. Defines how many months the value is distributed over. |
The Save button is only enabled when name, priority, attribute value, attribute, and collection are filled in.
Actions and modals
- Create new: opens
PaymentQueueModalComponentin creation mode →POST /v1/assets/createPaymentQueues. - Edit (pencil): opens the same modal with the queue loaded (edit mode) →
POST /v1/assets/updatePaymentQueues. The Name field is locked. - Delete (trash): calls
POST /v1/assets/deletePaymentQueues. On success the page reloads.
Business rules / considerations
Attention
- NFT selection is done by collection + attribute + value: if the attribute/value does not match exactly what is in the NFTs, the queue will be empty.
- The Name is immutable after creation.
- Priority is what orders the payment — queues with conflicting priorities can produce an unexpected payment order. Plan the numbering carefully.
- Configuring as Installment without providing Percentage/Months leaves the installment rule incomplete.
- Financial values: the values actually paid come from the
price_paidof each NFT (during execution) and are handled as BigNumber — without rounding. - Idempotency: the execution of each order is protected (an NFT already paid is not paid again) and transactions follow FinLib idempotency (
E00021= already processed = success).