Partial delivery: how it happens and how a fair refund is calculated

Partial delivery is the state buyers understand last. The order did not fail, the supplier did not disappear, and the money did not vanish. The supplier delivered less than the ordered quantity and reported the missing units. The panel owes you the difference, and the size of the difference is arithmetic, not negotiation.

This guide explains how a partial happens, the exact formula a fair panel uses, and the three symptoms that tell you whether the refund is correct, missing or waiting for a number. It also explains what happens when the supplier finishes the remaining delivery after the refund.

How a partial happens

The supplier accepts an order for a quantity, then delivers against a pool of accounts or a platform limit. If the pool runs out, if the platform slows the delivery, if the service has a cap below the ordered quantity, or if the link restricts who can be added, the supplier can stop short. The supplier then reports a partial status with a remains number.

The remains number is the supplier's statement of how many units are still outstanding. It is the only number the panel can use for the refund. A partial without remains is a status without a quantity, and a quantity is what a refund needs.

A partial can also arrive after a long in-progress period. The order page shows in progress while the supplier works, then partial when the supplier stops. The transition is a result, not an error. The error would be a panel that leaves the order in progress forever and never reports the result.

The symptom that brings people here

What you see: the order says partial, the wallet shows a credit, and the credit is smaller than the missing quantity multiplied by the rate you remember.

What it means: the refund is calculated on the charge you actually paid, not on the list rate, and the result is floored to the smallest wallet unit. A small gap is rounding. A large gap means the remains number is different from the one you assumed.

Next action: open the order page, read the remains the supplier reported, and compare it with the credit note. If the two do not match the formula, send support the order id and both numbers.

The second symptom is a partial with no credit at all. That happens when the supplier reports partial without a remains count. The order engine records the status and says that no refund was calculated yet, because there is no number to calculate. The next action is to ask for the remains in writing, not to ask for a refund in general.

The third symptom is a partial that later becomes completed. The supplier found the remaining units and finished the order. The order page shows completed, and the event log records that the remaining delivery finished after a partial refund, with no extra charge. You keep the refund and the units. That is not a double payment; it is the supplier completing late.

Formula: what a fair panel uses

The refund is proportional to the undelivered share of the order. In the order engine the target refund is the charge multiplied by the undelivered units, divided by the ordered units. The engine stores the total already refunded and credits only the difference, so polling the same supplier answer twice cannot pay twice.

The supplier cost is refunded on the same proportion, against the supplier's own ledger. That part is internal, but it explains why the customer refund can be automatic: the panel is not absorbing the whole missing share, it is passing the supplier's credit through and keeping the two ledgers aligned.

The arithmetic uses integer micro-dollars. One dollar is one million micro-dollars, and the division is floored. The difference between a hand calculation and the stored refund is at most one micro-dollar, which is far below a cent. If the gap is larger than that, the cause is the remains number or the charge, not the rounding.

The formula also explains the ceiling. The refund cannot exceed the charge, because the target is a share of the charge and the engine pays only the difference between the target and what was already refunded. A supplier that reports a remains larger than the ordered quantity is clamped to the order quantity before the calculation.

Worked example

Take a hypothetical 10,000 unit Instagram followers order at the median rate. The charge is $7.35. The supplier delivers 7,300 units and reports 2,700 remains. The order becomes partial.

The undelivered share is 2,700 of 10,000. At the median rate, the missing share is worth $1.9845, and that is the amount credited to the wallet. The delivered share is worth $5.3655, which is what the order effectively cost after the credit.

Check the two numbers against the charge. The delivered value plus the refund equals the charge, up to the smallest wallet unit. If they do not add up, one of the three inputs is wrong: the charge, the quantity or the remains. The order page has all three, which is why the ticket should quote all three.

Remains reported	Refund at the median rate	What it means
9,900 of 10,000	$7.2765	The supplier delivered almost nothing
9,000 of 10,000	$6.615	A small delivery against a large order
5,000 of 10,000	$3.675	Half the order arrived
2,700 of 10,000	$1.9845	The worked example above

Refunds are calculated on the charge actually paid. The table uses the median market rate for a hypothetical 10,000 unit order.

What a fair policy does

A fair policy credits the missing share automatically, without a ticket. The arithmetic is deterministic and the panel already has the three inputs. Making the customer ask for it turns a database entry into a support queue and gives the panel a reason to delay.

The credit should appear in the wallet with the order's public id and a note that names the partial delivery and the remains used. The order page should show the same remains. Two places, one number, no room for a different story in a chat message.

The policy should also say what happens if the supplier later completes the order. The correct answer is that the order becomes completed and no extra charge is made. The customer keeps the refund for the units that were missing at the time and receives the late units without paying twice. A policy that reverses the refund when the supplier finishes late is a policy that punishes the customer for the supplier's delay.

The policy should distinguish a partial from a refill. A partial is about units that never arrived. A refill is about units that arrived and then dropped. The two remedies use different evidence and different clocks. Mixing them lets a panel answer a delivery question with a refill promise, which delays the refund.

When the supplier reports partial without remains

The order engine cannot calculate a refund without a remains number. It records the partial status and writes an event that says no refund was calculated yet. The order stays partial, and the wallet does not move. That is the honest behavior, because a refund without a number would be a guess.

The next action is precise: ask support for the supplier's remains in writing. Quote the order id and the quantity. If the supplier cannot produce a remains number, the panel should treat the order as undelivered in full or ask the supplier to cancel it, depending on the service terms. Either way, the customer should not be left with a partial status and no path.

A support reply that says "the order is partial, we are checking" is not enough. The missing fact is the remains. Without it, neither the customer nor the panel can compute the credit.

How to check the wallet

The wallet entry for a refund has the kind refund, the order's public id as its reference, and a note that names the partial delivery. Compare the credit with the formula. If the credit is present and the arithmetic matches, the money side is closed even if the order page still shows partial while a correction is pending.

If the credit is absent and the order page shows partial with a remains, the refund is missing. Send support the order id, the remains and the charge. If the credit is present but the amount is wrong, send the same three numbers and the credit amount. The panel can recompute from the stored fields without asking the supplier again.

If the order later becomes completed, check that no second charge appeared. The event log should say the remaining delivery finished after a partial refund, with no extra charge. A second charge on a completed-after-partial order is a bug, and the order id plus the two wallet entries is the evidence.

The three inputs and where to find them

The formula needs three numbers, and each one has a home on the order page. The charge is the amount debited from the wallet at placement. The quantity is the number you ordered. The remains is the supplier's statement of what is still outstanding. If any of the three is missing, the formula cannot run, and a refund without it is a guess.

The remains is not the same as the live public count. The count can be lower than the start count plus the delivered quantity because accounts dropped after delivery, because the platform is still validating the delivery, or because the supplier's report and the platform's display are out of step. A drop after delivery is a refill question. A short delivery at the moment the supplier stops is a partial question. The order page should let you tell them apart by showing the remains the supplier reported, not only the count you can see.

The charge is also not the list rate. The rate is per 1,000 units and the charge is the rate multiplied by the quantity, divided by 1,000, then rounded up once at the end. A refund calculated on the rate instead of the charge can differ by the rounding step, which is small but visible on a small order. Use the charge from the wallet, not the rate from the service row.

A partial is not a cancellation

A cancellation stops the order and returns what is still owed. A partial delivery records what arrived and returns the missing share. The money can be similar when the remains is the whole undelivered quantity, but the states are different and the history matters for a later refill.

If a partial order is canceled afterwards, the engine refunds the difference between the charge and what was already refunded, not the full charge again. The customer receives the missing share once. The order state changes to canceled or refunded, and the delivered units stay delivered. A panel that refunds the full charge after a partial credit has paid twice, and the ledger will show it.

The distinction matters for the refill window too. A canceled order is not a completed order, so it cannot be refilled. A partial order that later completes can be refilled against the delivered quantity. If the supplier offers to finish the order, waiting for completion can preserve the refill path; cancelling closes it.

What to do next

If the order is partial and the wallet credit matches the formula, record the remains and the credit, then decide whether the delivered share is enough for the campaign. A partial that covers a large share of the order can still be useful. A partial that covers a small share is a failed order with a refund attached.

If the order is partial and the credit is missing, ask for the remains first. The refund follows the number. A ticket that asks for money without the number invites a reply that asks for the number, and the loop costs more time than the refund.

If the order is partial and the supplier later completes it, keep both facts: the refund and the late delivery. The order page should show completed, and the event log should show the sequence. If a future refill is requested, the refill is measured against the delivered quantity, not against the refunded share.

For the policy that should govern the refund, read refunds, cancellations and queues. For the state sequence around the partial, read the order lifecycle. For the written rules, open the refund page, and to follow a specific order, use the tracking page.