Skip to content

Payment Queue Orders

Access Prerequisites

  • Permission (module): processPaymentQueue (controls UI buttons) + manageToken (required by the queue route backend)
  • License/Feature: None specific.
  • Menu container: GENERAL → Charges group (route /manage-payment-queues-timelines)

Relationship with "Payment Orders" (court-ordered payments)

This screen (internal label "Payment Orders", route /manage-payment-queues-timelines) is the execution of the Payment Queues — the NFT buyback queue by priority. Do not confuse it with the Payment Orders screen (/manage-orders), in the Operations group, which handles court-ordered payment requests and allocations.

What it is / when to use

This screen lists, in the priority order defined by the queues, each individual NFT that is in the payment queue and allows the operator to settle (approve) the payment for each one. It is the operational step that brings the configuration made in Payment Queues to life.

When an order is approved, the system:

  1. Pays the current NFT 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 (the holder no longer owns it);
  3. Marks the order as paid and reorders the remaining queue entries.

Prerequisites

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

Step by step

  1. Go to Charges → Payment Queue Orders (route /manage-payment-queues-timelines).
  2. The list comes sorted (field order) — from highest to lowest priority. Each row is an NFT.
  3. Identify the NFT to pay by the asset Name and the NFT ID.
  4. For unpaid orders, click the check (Approve) icon on the row.
  5. The system executes the payment to the holder, returns the NFT to TKN_OWNER, marks the order as Paid = Yes, and reloads the page.

Filters and columns

ColumnWhat it showsData source
NameName of the NFT asset/collectionassetName (resolved from asset_id)
OrderNFT's position in the queue (effective priority)order
NFT IDOn-chain identifier of the NFTblockchain_token_id
PaidWhether the order has already been settled (Yes/No)paid
ActionApprove button (check), visible only when paid = false

The listing itself is the "timeline": the display order reflects the priority configured in the queues. Already paid orders remain visible with Paid = Yes, but without any action.

Actions and modals

  • Approve (check): calls POST /v1/assets/executePaymentQueue with the order id. There is no confirmation modal — the action is immediate. On success, displays a snackbar and reloads the page.

Business rules / cautions

Attention

  • Approval is immediate and without confirmation — one click already triggers the payment. Check the NFT (Name + NFT ID) before proceeding.
  • The backend blocks repayment: if the order is already paid, executePaymentQueue throws "It was already paid". If the NFT or user is not found, the operation fails without paying.
  • The amount paid is the NFT's price_paid (what the holder paid), not a value entered on the screen.

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 is deducted from 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 = success).
  • APPROVED status: the holder must be approved to receive the payment in their wallet.