Skip to main content

Transaction States

TrexWallet APIs expose transaction status as TransactStateEnum flags. State is additive, so one transaction can contain multiple flags.

Canonical transaction states (TransactStateEnum)​

StateValueDescription
Draft0Created but not yet started.
Created1Accepted and waiting for the next lifecycle step.
Confirmed2Confirmed in flows that require explicit confirmation.
Predicted4Expected movement marker before final settlement.
Verified8The transaction type's own pre-final gate has passed; the meaning is type-specific.
Blocked16Temporarily blocked from further movement.
Canceled32Canceled; any applicable reserve is returned.
Failed64Reserved compatibility bit; not normally returned as the sole terminal outcome.
Finished128Finalized operation.
Important

State is handled as OR-composition (additive flags), not as a single overwritten value.

Verified is type-specific​

Do not interpret Verified as one universal compliance state:

Transaction typeMeaning of Verified
IncomeThe partner_info gate is satisfied. It is automatic when the terminal does not require partner info, or set after the required data is supplied.
OutcomeCompliance has released the withdrawal for dispatch/finalization (AmlConfirm on address status).
TransferOrderThe payout's own recipient and required metadata gate is satisfied; the held payout leg can be released.

Completion rules​

Two independent checks — do not mix them:

  1. Is the transaction completed? — numeric threshold:

    • Not completed (active): state < Canceled (< 32)
    • Completed (terminal): state >= Canceled (>= 32)

  2. Which exact outcome? — bit check (each is its own flag):

    • Canceled (32) — cancelled
    • Failed (64) — failed
    • Finished (128) — finished successfully
    • Blocked (16) — AML blocked (not terminal by itself)

Threshold >= Canceled answers "can we still operate on this tx?" (no). Outcome name is taken from the actual flag, not from a range.

Payment order (tx_type = PaymentOrder)​

GET /payment/v1/get_order_info and GET /private/v1/get_payment_order_info return the canonical state bitmask without converting it to a separate string lifecycle. Use the same completion checks as above:

  • terminal/cancel path: state has Canceled
  • terminal/success path: state has Finished and does not have Canceled
  • pending path: neither Finished nor Canceled is set

Payment statistics counters​

For finished / cancelled / pending aggregates:

cancelled = state has Canceled
finished  = state has Finished AND NOT cancelled
pending   = everything else

Payment order lifecycle (high level)​

stateDiagram-v2
    [*] --> Draft: put_payment_order (open flow)
    Draft --> Predicted: order_start (alias payment_order_start) / locked flow create
    Predicted --> Finished: network settlement + link
    Predicted --> Canceled: cancel / expiry / failure

API string statuses (payment flows)​

confirm_crypto returns plain ApiResponse (success/error). The order's canonical TransactStateEnum bitmask is exposed via GET /payment/v1/get_order_info (PaymentOrderOut.state) and GET /private/v1/get_payment_order_info (PaymentOrderInfoOut.state).

Remaining endpoint-local string statuses (small, fixed sets — kept for clarity in synchronous one-shot responses):

  • PaymentResult.status (internal pay): completed, failed
  • RefundResult.status (synchronous refund_payment response): always completed on success; failures come back as an ApiResponse error, not a status string
  • RefundStatus.status (get_refund_status): created, completed, cancelled

Transaction type values (TransactTypeEnum)​

The full value-to-name mapping lives in the admin reference: Transactions and Orders admin. The same numeric values are used by API tx_type fields and estimate_fee.