What happens to your order between payment and delivery

An order does not go from payment to delivery in one step. It passes through a sequence of states, and each state has a different owner: the panel, the payment layer, the supplier, or the platform. Knowing who owns the state tells you what to do when it does not move.

This guide follows one order from the moment the wallet is charged to the moment the count is final. It explains what each state means, what should be visible on the order page, and where orders usually get stuck. It uses the same status names the order page uses, so you can match the explanation to what you see.

Payment is not delivery

The first confusion is the wallet. Paying for an order charges your wallet, and the charge happens at placement. It does not mean the supplier has accepted the order, and it does not mean the delivery has started. It means the panel has reserved the amount and created an order.

A fair panel separates the wallet entry from the order state. The wallet shows a debit with the order id. The order page shows pending, placing or queued. If the order cannot be placed, the charge is refunded in full. If it is placed and partially delivered, the missing share is refunded. The wallet is the ledger; the order page is the story.

This separation matters because a buyer who sees a debit and no delivery may assume the money is gone. It is not gone. It is held against an order that has a state and a remedy. The order page is where the remedy is visible, which is why a panel that hides the state is a panel that turns every delay into a support ticket.

The states of an order

State	What it means	Who owns the next step
Pending	The order exists and is waiting to be placed	The panel
Placing	The panel is sending the order to a supplier	The panel and the supplier API
Queued	The order is waiting for supplier funds or a queue slot	The supplier
In progress	The supplier has accepted and the count is moving	The supplier
Completed	The supplier reports the full quantity delivered	The platform and the pool
Partial	The supplier delivered less than ordered	The panel, for the refund
Canceled	The order was stopped before or during delivery	The panel, for the refund
Refunded	The charge has been returned to the wallet	The wallet ledger

The states used by the Talon order page. A panel may use different words for the same sequence.

Two states are easy to confuse: queued and in progress. Queued means the order has not started. In progress means it has. A queued order can still be refunded if the queue times out. An in-progress order is in the supplier's hands, and the remedy is delivery or a partial refund, not a cancellation.

Partial is not a failure of the order page. It is a result. The supplier delivered what it could, and the panel owes you the difference. A fair panel marks the order partial, refunds the missing share and closes the loop. A panel that leaves a partial order in progress forever is hiding a result it does not want to explain.

Placement: API or by hand

A panel that places by API sends the order to the supplier within seconds and receives a supplier order id. The order page can show that id, and support can use it to ask the supplier what happened. A panel that places by hand waits for a person to copy the order into the supplier's dashboard. The delay is not the only difference: the manual path has no supplier id until someone types it, so the panel cannot see the order's state in real time.

Most small panels start manual and move to API as they grow. That is a normal path. The problem is a panel that claims API placement but cannot show a supplier id. If the id is missing, the claim is decoration.

API placement also changes the failure modes. An API can reject an order because the supplier balance is low, the service is paused, the link is invalid or the quantity is outside the limits. A good panel checks those before charging. A weak panel charges first and discovers the rejection after. The order page should show the rejection reason, not a generic error.

The queue: supplier queue and panel queue

There are two queues in every order. The panel queue is the time between your payment and the panel sending the order to the supplier. The supplier queue is the time between the supplier accepting the order and the delivery starting. The start estimate on the service row usually describes the second, not the first.

A panel queue is measured in seconds if the API is healthy and in hours if the panel is manual or out of supplier balance. A supplier queue is measured in minutes or hours depending on the service and the time of day. When an order is late, the first question is which queue it is in. The order page should answer that with a state, not a guess.

A queue timeout is a normal policy. If an order cannot be placed before a deadline, the panel refunds it in full. The deadline should be stated. A panel that holds a queued order indefinitely is not protecting the customer; it is protecting its own balance sheet.

Start count and remains

When the supplier starts, it reads the current count on the profile or channel. That number is the start count. The order then adds the ordered quantity, and the remains field tracks how much is still outstanding. When remains reaches zero, the order is complete.

The start count is the baseline for a refill. If the order delivered 10,000 and the count later falls, the refill is measured against the start count plus the delivered quantity. If the start count was wrong, the refill calculation is wrong. This is why the start count should be visible on the order page and why a screenshot before the order is useful.

Remains is also the basis for a partial refund. If the supplier reports 2,700 remains on a 10,000 order, the undelivered share is 2,700 and the refund is calculated from it. The panel should show the number it used. A refund without the remains is a number without a basis.

Completion, partial and refund

Completion is the supplier's claim that the full quantity was delivered. It is not a guarantee that the count will stay. The platform can remove accounts after completion, and the refill window is the remedy for that. Completion closes the delivery, not the risk.

Partial is the supplier's claim that it could not deliver the full quantity. The panel should refund the undelivered share automatically. The refund is a wallet credit, not a new order, and it should be visible in the ledger with the order id. If the panel offers a refill instead of a refund for undelivered units, the policy is mixing two remedies that should be separate.

Canceled is the state for an order stopped before delivery. The refund depends on whether the supplier had already started. A fair policy states the window: before acceptance, full refund; after acceptance, the supplier's cancellation rules apply. A panel that cancels without a refund after acceptance is not cancelling; it is keeping the money.

Refunded is the state that closes the money side. The order can be refunded in full, in part, or not at all. The wallet entry is the evidence. A refund that exists only in a chat message is not a refund.

A worked timeline

Take a hypothetical 10,000 Instagram followers order at the median rate in our market table. The full charge is $7.35. The order is placed, the wallet is debited, and the order page moves from pending to placing to queued. None of those states means the count has moved.

When the supplier accepts, the order moves to in progress and the start count is recorded. The count begins to move. If the supplier delivers 7,300 and reports 2,700 remains, the order becomes partial. The delivered share is worth $5.37 and the missing share is worth $1.98. A fair panel credits the missing share and shows the remains it used.

If the order completes at 10,000 and the count falls to 7,300 inside the refill window, the remedy is a refill, not a refund. The refill is measured against the delivered 10,000. The two cases look similar on the profile and are completely different on the order page. That is why the state matters.

Where orders get stuck

• Supplier balance. The panel's account with the supplier is empty, so the order waits. A good panel checks before charging or tops up quickly.
• Paused service. The supplier paused the service after the panel published it. The order is rejected or queued until the service returns.
• Invalid link. The profile or video is private, deleted or in the wrong format. The supplier cannot deliver, and the panel should say so before charging.
• Quantity outside the limits. The order is below the minimum or above the maximum. The checkout should catch it; the supplier will reject it.
• Platform limit. The platform is rate-limiting the supplier's delivery. The order slows down or stops, and the supplier reports remains.
• Manual queue. The panel is placing by hand and the person is offline. The order waits without a supplier id.

Each stuck state has a different remedy. A supplier balance problem is the panel's to fix. A paused service is a catalogue problem. An invalid link is yours. A platform limit is nobody's fault, but the refund policy decides who carries the cost. A manual queue is a process problem the panel chose.

What a fair order page shows compared with a vague one

What you need	A fair order page	A page that hides the process
Current state	A named state with a timestamp	A spinner
Supplier order id	Visible once placed	Missing until support provides it
Start count	Recorded and shown	Not shown
Remains	The number the refund uses	A total with no breakdown
Refund	A wallet entry with the order id	A promise in a chat
History	Every state change with a time	Only the latest state

A qualitative comparison. It contains no market figures.

The history is the part buyers underestimate. A single current state tells you where the order is. A history tells you how it got there, which is what you need when a state has not moved for a day. A panel that stores the history can answer "when did it change" without asking the supplier. A panel that does not store it can only guess.

What the catalogue says about refunds and refills

In the current catalogue, 1 active services carry a refill flag and 1508 carry a cancellation flag. Those counts are a property of the rows, not a promise about any single order. They tell you how common each remedy is before you buy.

Catalogue flag	Active services
Services with refill enabled	1
Services with cancellation enabled	1508
Active services in total	3188

Counts are read from the active catalogue when this page is rendered. A flag on a row is not a guarantee that the supplier will honour it on a specific order.

The gap between the two counts is the useful part. A catalogue where refill is common and cancellation is rare is a catalogue built around replacement. A catalogue where cancellation is common and refill is rare is built around stopping orders. Neither is automatically better. The flags tell you which remedy the panel expects to use.

What to do at each stuck state

If the order is pending, wait for the placement window and check whether the panel has a supplier balance problem. If it is queued, ask for the queue position and the refund deadline. If it is in progress, ask for the supplier's reported remains. If it is partial, check the wallet for the missing share. If it is completed and the count falls, check the refill window.

In every case, use the order id and ask for the state, not the outcome. "What state is order 12345 in, and what is the next step?" is a question a support team can answer. "Where are my followers?" is a question that invites a story. The order page is the shared source of truth; the ticket should point at it, not replace it.

For the money side of the same sequence, read refunds, cancellations and queues. For the delivery test, read how to test a new panel. To follow a real order, open the tracking page or the support page.