Skip to main content
Every checkout in Nova.Pay — whether initiated through a hosted checkout page, a programmatic cart, or a charge link — produces an order that progresses through a defined set of statuses. Understanding this lifecycle lets you build reliable fulfillment logic, handle edge cases like partial payments and refunds, and keep your customers informed at every step. You can query an order’s current status at any time using the REST API, and you can react to transitions in real time via webhooks.

Status Reference

The table below describes every possible order status and what it means for fulfillment:

Lifecycle Diagram

The steps below show the happy path from order creation to payment and optional refund:
1

Order created → pending

The order is created when the customer initiates checkout. At this point no payment has been attempted and the status is pending.
2

Payment initiated → waiting_payment

The customer submits a bank slip or Pix payment request. Nova.Pay generates the payment voucher or QR code and the order moves to waiting_payment. For instant methods like credit card, this status may be skipped entirely.
3

Payment confirmed → paid

The bank or payment network confirms receipt of funds. The order transitions to paid and you can safely fulfill the purchase.
4

(Optional) Refund issued → partially_refunded or refunded

If you initiate a refund via the API, the order moves to partially_refunded (if partial) or refunded (if full). Reverse any fulfillment actions as appropriate.
Not every order follows this exact path. An order may jump directly from pending to paid for synchronous payment methods, or from waiting_payment to cancelled if a boleto expires unpaid.

Querying Order Status

You can check the current status of any order at any time using the Orders API. An API key is required.
Example response:
Use the top-level status field to drive your fulfillment logic. The nested payments array gives you the status of each individual payment transaction associated with the order.

Payment Statuses vs. Order Statuses

Individual payment records have their own status that is separate from the parent order status. A single order can have multiple payment records — for example, a split credit card purchase creates two payment records, or a retry after a failed attempt creates a new record alongside the failed one.
Do not rely solely on individual payment statuses to trigger fulfillment. Always check the parent order status — an order only reaches paid when the full amount has been confirmed across all payment records.

Subscriptions

When a payment belongs to a subscription, the payment response includes "is_subscription": true. Use this flag to distinguish recurring charges from one-time purchases in your fulfillment and notification logic. Subscription orders cycle through the same statuses as standard orders, but they are created automatically on each billing interval rather than by customer action.