Payment Queue Timeline

Access prerequisites

• Permission (module): processPaymentQueue (controls the UI buttons) + manageToken (required by the backend for /v1/assets/... routes)
• License/Feature: None specific.
• Menu container: GENERAL → Charges group → Payment Orders item (icon timeline, route /manage-payment-queues-timelines)

Same screen, two names

In the sidebar this item appears as "Payment Orders" (i18n label paymentQueuesTimelines, timeline icon). It is the execution, in priority order, of the Payment Queues — each row is an NFT to be bought back. The field-by-field detail of each NFT's settlement (what happens on approval) is in Payment Queue Orders; this page describes the prioritized timeline/listing and the process action. Do not confuse with the Payment Orders screen (/manage-orders), under the Operations group.

What it is / when to use

This screen is the payment timeline of the queues: it lists each individual NFT that entered a buyback queue (court-ordered debts, debentures, tokenized public debt, etc.), ordered by priority as defined in Payment Queues. This is where the operator processes (approves) the payment of each NFT, in order.

The display order of the table is the timeline: from the most prioritized (order lower) to the least. Already-paid orders remain visible with Paid = Yes, with no action available; unpaid ones show the approve button.

When approving an NFT, the system:

1. Pays the current holder the price_paid amount (what they paid for the NFT), from the platform wallet, in the tenant's fiat currency;
2. Transfers the NFT back to TKN_OWNER;
3. Marks the order as paid and reorders the remaining entries.

Prerequisites

• Permission: processPaymentQueue for the UI buttons; the backend validates manageToken on the routes (getPaymentQueuesTimelines, executePaymentQueue). Dual permission — CPM enum on the backend + dynamic module in the DB.
• License/Feature: None specific.
• Dependencies on other screens: the Payment Queues must be configured and have selected NFTs (by collection + attribute + value). The NFT holder must have a valid wallet and be APPROVED.

Step by step

1. Go to Charges → Payment Orders (route /manage-payment-queues-timelines).
2. The page loads the timeline (GET /v1/assets/getPaymentQueuesTimelines), already sorted by priority (most prioritized first). Each row is an NFT.
3. Identify the NFT by the asset Name and NFT ID.
4. On rows with Paid = No, click the check (Approve) icon.
5. The system executes the payment to the holder, returns the NFT to TKN_OWNER, displays the message "Queue processed successfully" and reloads the page.

Filters and columns

The screen is a prioritized listing (no search filters), paginated (5/10/25/100 per page, default 25).

Column	What it shows	Data source
Name	Name of the NFT asset/collection	assetName (resolved from asset_id)
Order	Position of the NFT in the queue (effective priority)	order
NFT ID	On-chain identifier of the NFT	blockchain_token_id
Paid	Whether the NFT has already been settled (Yes/No)	paid
Action	Approve button (check), visible only when paid = false	—

The table's own sort order (order) is the timeline: it reflects the priority configured in the queues. There is no creation button on this screen — the queue composition comes from the configuration in Payment Queues.

Actions and modals

• Approve (check): calls POST /v1/assets/executePaymentQueue with the selected order. There is no confirmation modal — the action is immediate. On success, displays the snackbar "Queue processed successfully" and reloads the page; on error, displays "Error processing queue".

Business rules / considerations

Attention

• Approval is immediate and without confirmation — one click already triggers the payment. Check the NFT (Name + NFT ID) before clicking.
• The backend blocks re-payment: if the NFT is already paid, executePaymentQueue rejects the operation ("It was already paid"). If the NFT or the holder is not found, it fails without paying.
• The amount paid is the NFT's price_paid (what the holder paid), not a value entered on the screen.
• Respect the order: the table is already prioritized; skipping rows out of order may go against the desired payment precedence.

Effective financial transaction

Approving an order pays real money to the holder and removes the NFT from them (it returns to TKN_OWNER). This is a settlement — treat it as irreversible from an operational standpoint.

• Financial values: price_paid is treated as BigNumber — no rounding. The payment leaves the platform wallet in the tenant's fiat currency.
• Idempotency: an already-paid NFT is not paid again (explicit paid guard); transactions to FinLib follow idempotency by externalId — E00021 ("already processed") is success, not failure (e.g.: retry after crash).
• APPROVED status: the holder must be approved to receive the payment in their wallet.

Related screens

• Payment Queues (queue configuration)
• Payment Queue Orders (settlement detail for each NFT)
• Payment Orders (court-ordered debts, /manage-orders)
• Back to Financial index