DataOrganizer

The “awaiting payment” column in the shop panel grows before the seasonal peak, and it is hard to tell whether this is normal or a cash leak. Unpaid orders in an online shop end up in revenue reports, often in campaign conversions too, yet never reach the bank account. Using a home appliance shop as an example, this guide shows how to calculate the rate and value of orders placed but not paid (excluding cash on delivery and retries), set your own benchmark per payment method, check how much they inflate MER and ROAS, and choose which payment process to fix first. Sudden payment failures are caught by daily monitoring; here the focus is the steady benchmark and its value in euros.

The scale in this guide’s example: of 1,100 prepaid orders, 88 were never paid, which is 8.0% of orders and 11.8% of value. After deducting retries by the same customers, €18,280 was actually lost in a single month.

Status strip

How much revenue gets stuck between order and payment

In the home appliance shop’s panel, September looks like a good month: 1,200 orders placed worth €185,000. The bank statement and the payment provider’s report show less, however, and the difference is not explained by accounting. Some orders stopped in the “awaiting payment” status and will never leave it.

The first step is to break down the total from the panel. 100 orders worth €9,500 are cash on delivery: the customer pays the courier on receipt, so their payment is only settled at delivery and they form a separate category. That leaves 1,100 prepaid orders worth €175,500; only these should be paid before the parcel leaves the warehouse.

The status only counts after the maturation window. Orders from the last days of the month may still be waiting for a bank transfer to clear, so the assessment falls on 8 October, 7 days after the end of September. The strip below shows what happened to every euro of prepaid orders (illustrative data).

Of 1,100 prepaid orders, 88 never received payment, totalling €20,640. That is how much revenue counted from placed orders overstates September: the dashboard shows €185,000, while paid prepaid orders (€154,860) plus cash on delivery (€9,500) come to €164,360. The difference is exactly €20,640.

Part of this amount is sales recorded under a different order number. 18 orders worth €2,360 are repeat orders: the same customer, identified by customer ID or hashed email address, placed and paid for a second order within 2 days. The money arrived, so these entries are not a loss, merely a duplicate record in the statuses.

The real loss is 70 orders worth €18,280, which is 10.4% of prepaid order value against 6.4% of their count. Value slips away faster than order count because payment is most often missing on large baskets; the breakdown by payment method later on shows which ones.

This calculation needs the status of every order. The purchase event in GA4 and the conversion in the ad platform are usually recorded on the thank-you page, at the moment the order is placed, and know nothing about what happens to it afterwards. That is why automated e-commerce analytics counts sales from shop orders together with their payment status, with data from ad platforms and GA4 added as channel context.

Before asking whether this is a lot, separate cash on delivery, repeat orders and orders still within the payment window. Only what remains can be compared with the benchmark and valued in money.

Definition

Unpaid order rate: definition and formula

The calculation requires three decisions before any counting: what goes into the denominator, from when an order is considered lost, and what to do with a customer who paid at the second attempt. Without them, the same shop can show 7.3%, 8.0% or 6.4%, and each of these figures will be formally correct.

The rate by value comes out higher than by count because it is mainly expensive baskets that go unpaid. The average prepaid order in the home appliances shop is about €159.50, while the average unpaid one is about €234.50. Instalment payments alone, with a €370 basket, account for 30 of the 88 unpaid orders (34% of the count) but as much as €11,100, or 54% of the unpaid value.

That is why decisions are based on the net value version. The count shows how often the payment process fails; the value shows how much cash it costs. The gap between them immediately indicates that the problem is concentrated in high-value baskets.

Mapping shop statuses to the three calculation buckets (status names differ between shop systems; what matters is their meaning):

Three pitfalls change the result more than the payment process itself:

1. Orders from the last few days counted as lost

   A standard bank transfer usually takes 1–2 working days to clear, so an order from 30 September paid on 2 October looks lost if the calculation is done on 1 October. A 7-day maturity window and assessing September only on 8 October remove this false alarm.

2. Cash on delivery in the denominator

   Cash on delivery has no prepayment status, so 100 such orders worth €9,500 dilute the result: 88 / 1,200 gives 7.3% instead of 8.0%, and €20,640 / €185,000 gives 11.2% instead of 11.8%. Uncollected cash-on-delivery parcels are a separate problem with a separate calculation.

3. Repeat orders counted twice

   A customer whose payment failed often places a second order and pays for it; the first one stays unpaid. A repeat order is a paid order from the same customer (the same order_customer_id or email_hash) within 2 days: in the example, 18 orders worth €2,360, which reduce the loss from €20,640 to €18,280.

This calculation only starts after the “place order” click. Cart abandonment and drop-offs in checkout steps before the order is placed are a separate problem, measured on GA4 sessions and events; it is covered in the guide to the session and checkout funnel. Here the customer has already entered an address and chosen a payment method, so every loss has an order number, amount and payment method in the shop.

Payment methods

Unpaid order benchmarks by payment method

A shop-wide average of 8.0% blends processes of a completely different nature. BLIK completes within seconds on the customer’s phone, a traditional bank transfer waits for the customer’s decision and for the bank to post it, and instalments wait for a credit decision. A shared rate only tells you that somewhere orders are not reaching payment.

The norm per payment method is the range of the unpaid rate over the three previous full months (here June–August), calculated with the same definition: prepaid orders only, a 7 day maturation window, retries subtracted separately. The current month is then read separately for each method: “within norm” or “above norm”.

The shop average also reacts to the payment method mix itself. When the share of instalments grows, the shop-wide rate goes up even though no payment process has broken. A norm per method separates a change in the mix from a genuine fault.

September in a home appliances shop by payment method (illustrative data, assessed on 8 October, 7 day window):

The same figures shown as the payment choice the customer sees at checkout: the grey band on the 0–30% scale is the method’s own norm, the marker is September, and highlighted tiles have gone above their norm.

Two methods went above their own norm: card and traditional bank transfer. Card stands at 5.0% against a norm of 3.0–4.0%, but five of the nine unpaid orders were paid again by the same customers within two days, so the net loss was €600. Traditional bank transfer stands at 26.3% against a norm of 18–22% with not a single retry, which means €4,725 lost net.

Instalments are within their norm, yet account for 61% of the net lost value (€11,100 out of €18,280). A rate of 25.0% with an average basket of €370 costs more in money terms than the other four methods combined (€7,180). The norm says the process is working as usual; the amount shows that this “as usual” costs the shop the most.

Each method loses payments for a different reason, which is why the norms differ so much:

• Instalments and deferred payment: the order is created before the credit decision; some customers are refused, others give up during the application when they see the form and the terms.
• Traditional bank transfer: the customer receives the transfer details and puts off payment; without a reminder the order expires after the deadline.
• Card: authorisation fails (limit, additional verification at the bank), and the customer usually retries the purchase straight away, so the share of retries is high.
• BLIK and instant online transfer: payment completes within tens of seconds, so unpaid orders are mainly abandonments on the bank’s or payment provider’s page.

The cause of a specific transaction is shown in the payment provider’s dashboard (reason for refusal, stage of abandonment). Order data from the shop shows the scale and location: which method, how many orders, how much money and whether the result deviates from its own norm. The order of work is therefore fixed: first the shop data points to the method, then the provider’s dashboard explains the cause.

Channels and ROAS

Unpaid orders, MER and channel ROAS from GA4

Channel revenue in GA4 and the ad platforms is counted when the order is placed, before it is known whether it will be paid. The table below splits September’s spend and GA4 revenue by channel and applies the shop-wide paid share of value (88.8%) as a uniform discount to GA4 ROAS.

Every channel with spend looks better in the report than in the bank account. Meta shows a ROAS of 7.33 on revenue counted at placement; a uniform discount by the shop-wide paid share (88.8% of value) brings it to 6.52, and Google Ads from 7.00 to 6.22. The split between channels comes from GA4, so it is an estimate, and the discount is the same for every channel because the paid share comes from the shop’s order statuses as a whole; the result on money actually received is MER.

Other sources show the highest ROAS, but on a spend of only €500. A result on such a small budget is too unstable to set a norm, so a row like this is monitored over the following months before any decision is made. Organic and direct traffic have no ad spend, so they appear only in the GA4 revenue split and in MER for the whole shop.

The same spend gives two different results for the whole shop:

The 12.6% difference comes solely from when revenue is counted. 88 orders worth €20,640 entered the result before payment and were never paid; their average basket is about €234.50 against about €159.50 for prepaid orders as a whole, so it is mainly the more expensive orders that go unpaid. The campaigns did not change by a single euro; only the definition of revenue changed.

The same effect appears in ad platforms and in GA4. If the purchase event fires on the thank-you page before the customer pays, the ad platform and GA4 also count a conversion for an order that gets stuck at the payment provider. That is why the shop’s result is accounted for on paid orders (MER), channel ROAS from the platforms and GA4 is read as an estimate counted at placement, and GA4 coverage (GA4 purchase transactions against shop orders for the same days) is calculated on daily totals; more on gaps and surpluses in measurement in the guide to missing conversions and Consent Mode.

Campaign figures are read with the same caution. Campaign revenue reported by the ad platform or GA4 is counted at placement, so it stays an estimate, while the result on paid orders is assessed for the shop as a whole through MER. A campaign that deviates from its norm (spend rises, orders do not) is reviewed first.

Before shifting budget between channels, recalculate MER on paid orders and treat channel ROAS from GA4 or the platforms as counted at placement. The channel split stays an estimate from GA4 or the platforms, and the result on money that has actually reached the account is read through MER for the whole shop.

Fix matrix

Order of fixes: deviation from the norm and value

A list of payment methods with their rates does not yet tell you where to start. The order is set by two numbers at once: deviation from the method’s own norm (whether something has changed in the payment process) and net lost value (how much it costs each month). The first points to a fault to reverse; the second tells you whether it is worth starting with that one.

The procedure has five steps and always works on the same definition as in the previous sections:

1. Calculate net lost value per payment method

   Unpaid orders after the 7-day window, minus orders re-placed and paid by the same customer within 2 days. In September: instalments €11,100, bank transfer €4,725, pay-by-link transfer €1,120, BLIK €735, card €600; in total €18,280.

2. Compare the rate with the method’s own norm

   The norm comes from the three previous months, calculated in exactly the same way. Two methods are above the upper limit: bank transfer (26.3% against a norm of 18–22%) and card (5.0% against a norm of 3.0–4.0%).

3. Place the method in the matrix

   Horizontal axis: within the norm or above it. Vertical axis: net lost value; the threshold is set to suit the size of the shop, and here the split is at around €2,500 a month.

4. Assign the type of action

   Each quadrant means a different kind of work: reversing a fault, designing a new step in the process, monitoring in the payment provider’s dashboard, or a routine monthly review.

5. Measure the effect in the next full month

   The same definition: a 7-day window, cash on delivery excluded from the denominator, re-placed orders deducted. Changing even one exclusion will show an improvement that never happened in the process.

Fix priority matrix (household appliances shop, September, net lost value, illustrative data):

Fix now: traditional bank transfer. A rate of 26.3% against a norm of 18–22%, and €4,725 lost net. A deviation from the method’s own norm means something in the process has changed: the wording of the order confirmation with the transfer details, the payment deadline, or a reminder that stopped being sent before cancellation.

Process redesign: instalments. The rate of 25.0% falls within the 22–28% norm, yet €11,100 accounts for 61% of the net lost value. Nothing has broken here, so improvement requires a new step, e.g. contacting the customer after a declined credit decision and offering a different payment method for the same basket.

Monitor: card. The rate of 5.0% is above the 3.0–4.0% norm, but 5 of 9 customers retried the payment and completed it, so the net loss is €600. The payment operator’s panel will show whether failed authorisations persist over the following weeks.

Within norm: BLIK and instant transfer. Together €1,855 net (€735 + €1,120) with rates inside their norm ranges. These methods only need a monthly review using the same definition.

The scenario calculation shows what the first move is worth:

• Traditional bank transfer from 26.3% to 10%: 10% of 80 orders means 8 unpaid instead of 21, i.e. 13 × €225 = €2,925 per month.
• Instalments, recovering one third of lost orders: 10 × €370 = €3,700 per month.
• In total €6,625 per month, i.e. 36% of the current net loss (€6,625 / €18,280).

At peak season the stakes rise together with volume. At 1.8× volume, the net loss reaches approx. €32,900 (€18,280 × 1.8), and the potential of the fixes approx. €11,925 (€6,625 × 1.8). It therefore pays to fix traditional bank transfer before the peak, and to launch the instalment project early enough to measure the effect over a full month.

Decision thresholds separate a process fault from an outage. A method that stays above the upper limit of its own norm for two full consecutive weeks goes to diagnosis according to the matrix. A sudden rise in pending orders on a single day, e.g. after a payment failure at the operator, is an outage to be caught in daily anomaly monitoring the next morning; its time and cause are shown in the payment operator’s panel.

The order of fixes is set by a pair of numbers: the method’s deviation from its own norm and the net amount lost. A method above its norm with a large amount comes first, because something in its process has changed and that change can be reversed.

DataOrganizer

Unpaid orders in the DataOrganizer chat

The whole calculation from the previous sections rests on a single table: shop orders with their status. DataOrganizer retrieves them via the shop’s official APIs together with the fields the norm requires: order_status, order_payment_method, order_grand_total_amount, order_date_created, plus order_customer_id and email_hash to catch retries. Costs from ad platforms and channel data from GA4 sit alongside, so MER on paid orders is calculated in the same place, while channel figures from GA4 and the platforms stay an estimate counted at placement.

Data refreshes once a day and in the morning contains the complete previous day. This allows the unpaid rate to be read at two levels: a day against the pattern for the same weekday (Tuesday against Tuesdays), and a full month after the maturation window against the method’s own norm per payment method. The cause of an individual transaction (a bank decline, an abandoned instalment application) stays in the payment operator’s panel; shop data shows the scale of the problem and where it is growing.

The monthly review after the 7-day window closes looks like this (home appliance shop, September, illustrative data):

Over the month, the same conversation takes a shorter form. In the morning you can ask whether yesterday’s unpaid rate for a given method falls within the pattern for that day of the week; a sudden spike signals an outage, which the payment provider’s dashboard confirms, while a mild deviation is only confirmed by a second day. The full verdict against the norm comes after the maturation window closes, once traditional bank transfers have had time to clear.

Connecting the shop, ad platforms and GA4 is done on your own, without a developer. You pay for connected sources, and current rates are on the pricing page. From the first refresh, order statuses, payment methods, ad spend and GA4 channels sit in one place, so the table of norms from the previous three months is calculated from history rather than from manual exports from the shop admin panel.

Methodological note: the figures in the examples are illustrative. September is assessed on 8 October (7-day maturation window), cash on delivery orders are excluded from the denominator as a separate category, and a retry means a paid order from the same customer within 2 days. DataOrganizer has no data on returns or refused deliveries, so the calculation ends at payment. After changing payment provider or adding a new method, norms are recalculated from the date of the change.

Methodological note: the figures in the examples (a home appliances shop, September, assessed on 8 October) are illustrative and serve only to show the calculation. The rate is calculated after a 7-day maturation window, without cash on delivery in the denominator and after deducting retries by the same customer; shop data does not cover returns or refused deliveries, and after a change of payment provider the norm is recalculated.

FAQ

Frequently asked questions about unpaid orders

What rate of unpaid orders is normal for an online shop?

There is no single value for all shops, because each payment method behaves differently: in the example home appliances shop the norm for BLIK mobile payments is 2.5–3.5%, and for instalments 22–28%. Your own norm is set per payment method from the previous three full months, counting only prepayments older than the maturation window and deducting retries by the same customer. The shop average (here 8.0% by count and 11.8% by value) shifts with the payment mix, so on its own it does not tell you whether something has broken.

Why do customers place an order and not pay?

The mechanism depends on the method: with instalments the customer abandons the application or is declined, with traditional bank transfer they postpone payment, and with cards the authorisation fails and often ends in a quick retry. Shop data shows the scale and location of the problem per payment method: how many orders and how much money. The cause of a specific transaction is known to the payment provider’s dashboard.

After how many days should an unpaid order be cancelled?

The cancellation deadline follows from the shop’s terms and the payment method, and a traditional bank transfer usually clears in 1–2 working days, so too short a deadline cancels orders that would still have been paid. For analysis, use a maturation window matched to the slowest method (7 days in the example); only after it does an order without payment count as unpaid. Before cancelling, it is worth sending a reminder with payment details, as this is the cheapest way to recover part of the value.

Should unpaid orders be counted in revenue and ROAS?

No: revenue and MER are calculated from paid orders from the shop, while placed orders can be reported separately as a demand signal. In the example, MER on placed orders is 12.33 and on paid orders 10.96, so counting before payment inflates the result by 12.6%. If the purchase event fires on the thank-you page before payment, ad platforms and GA4 also count unpaid orders, so channel ROAS from those sources is read as an estimate counted at placement, while the result on paid orders is MER for the whole shop (more in the guide on missing conversions).

How do you check unpaid orders per payment method in DataOrganizer?

DataOrganizer pulls orders from the shop with status, payment method, amount, date and a hashed customer identifier, and refreshes the data once a day with the complete previous day. In the chat, simply ask about unpaid prepayments per payment method against the three-month norm, excluding cash on delivery and deducting retries, and the assistant returns a table with the rate, net lost value and MER on paid orders. A sudden spike in pending orders on a single day shows up in the morning summary against the day-of-week pattern, as described in the guide on monitoring and anomalies.