Awaiting Payment Orders, Ecwid

Awaiting Payment Orders: orders stuck in AWAITING_PAYMENT for over 24h, usually a gateway issue or customer dropoff. How to read it, why it matters, and how to act on it.

Metrics type: Supporting Metrics • Category: Ecommerce Platform

Orders stuck in AWAITING_PAYMENT over 24h usually mean a payment-gateway issue or customer-side dropoff.

At a glance

Live count of orders sitting in AWAITING_PAYMENT, with the alert focused on those aged over 24 hours. On Ecwid an awaiting-payment order is one the customer started but never completed payment on, or one routed through a delayed method (PayPal pending, bank transfer, manual payment). A few of these is normal checkout noise; a pile of aged ones usually means the payment gateway is misbehaving or buyers are abandoning at the pay step.

What it counts	COUNT(orders WHERE paymentStatus = AWAITING_PAYMENT), evaluated in real time. The alert sub-counts those whose created_at is more than 24 hours ago.
API endpoint	GET /v3/{store-id}/orders?paymentStatus=AWAITING_PAYMENT (paged, max 100 per call, OAuth2 with read_orders scope). Webhook updates fire on order.created, order.updated, order.paid and clear the order from this count once it reaches PAID or CANCELLED.
What “awaiting payment” includes	Started-but-abandoned card checkouts, PayPal pending captures, offline/manual payment methods awaiting confirmation, and bank-transfer orders the merchant has not yet reconciled.
What it excludes	Orders already PAID, CANCELLED, or refunded. Pure cart abandonment that never created an order is not here (no order object exists).
Age threshold	The alert keys on >24h because most legitimate delayed methods clear well inside a day; anything older is a stuck order, not a slow one.
VAT / tax / shipping	Not relevant; this is an order-count and status card, not a value card.
Currency	number. A count of orders, not a money figure.
Time window	RT (real time). The card reflects the current live state, not a rolling window.
Alert trigger	>10 aged >24h. More than ten orders stuck beyond a day signals a gateway or checkout problem rather than ordinary pending noise.
Sentiment	ecwid_awaiting_payment_orders. Inverse: lower is better.
Roles	owner, finance.

Calculation

Calculated automatically from your Ecwid data. See the At a glance summary above for what the metric tracks and the worked example below for a typical reading.

Worked example

A small US supplements seller running an Ecwid widget on their Webflow site, snapshot taken 21 Apr 26.

The seller accepts cards via Stripe and also offers PayPal. Most card checkouts clear instantly; PayPal occasionally lands in a pending state that clears within minutes. On a normal day they carry two or three awaiting-payment orders, all under an hour old.

Snapshot	Today (21 Apr 26)	Typical day	Change
Awaiting Payment Orders (total)	19	3	+16
Of which aged over 24h	14	0 to 1	+13
Orders paid today	22	38	-16

Awaiting Payment (total):        19
Of which aged > 24h:             14   -> alert floor is >10, breached
Normal baseline aged > 24h:      0 to 1
Read: gateway or checkout-step failure, not pending noise

What it means for this seller. Nineteen awaiting-payment orders with fourteen of them older than a day is a clear break from the two-or-three-under-an-hour baseline. Combined with paid orders down 16 on the day, this is the classic signature of a payment-step failure: customers are reaching checkout and creating an order, but the payment is not completing. The order shell is written, the money never arrives.

For an Ecwid merchant the first checks are concrete. (1) Place a test order through the live widget and try to pay, this reproduces the customer experience directly. (2) Open the Stripe and PayPal dashboards and look for declined-payment spikes or an account hold. (3) Confirm the host site (Webflow here) loaded the widget correctly; a broken embed can render a checkout that cannot submit. (4) Check whether a recent theme or plugin change on the host site collided with the widget’s checkout script.

The card is a leading indicator of lost revenue. Each aged awaiting-payment order is a customer who tried to buy and could not. Recovering even half of fourteen stuck orders by fixing the gateway and sending a “complete your payment” nudge is real money a small store cannot afford to leave on the floor. Once the underlying issue clears, paid orders should rebound and the awaiting-payment count should fall back toward the normal handful within the next polling cycles.

Sibling cards merchants should reference together

Card	Why it matters next to awaiting payment	What the combination tells you
Total Orders	The completed side.	Awaiting-payment up + paid orders down = a gateway or checkout failure, not demand.
Pending Orders	The next stage.	Once payment clears, orders move to pending; watch the handoff between the two.
Conversion Rate	Funnel context.	CR dropping while awaiting-payment rises confirms buyers are stalling at the pay step.
Cancellation Rate	The cleanup.	Aged awaiting-payment orders often end as cancellations; a rise here foreshadows a cancellation bump.
Total Revenue	The money lost.	Awaiting-payment orders are revenue at risk; a stuck pile predicts a revenue dip.
Order Volume	Demand check.	Volume steady but paid orders falling = a payment problem, not a traffic problem.
Revenue at Risk	Quantified exposure.	Sums the value tied up in stuck orders so you can size the recovery opportunity.
Ecwid API Failure Rate Spike	Infrastructure check.	An API spike alongside aged awaiting-payment points to a platform-side issue, not your gateway.

Reconciling against Ecwid

Where to look in Ecwid’s own dashboard:

Ecwid Control Panel (my.ecwid.com) -> My Sales -> Orders -> filter Payment status = “Awaiting Payment” The filtered count is the apples-to-apples comparison. Sort by date to see which of those are aged beyond 24 hours.

For the gateway view, cross-check the Stripe and PayPal dashboards for incomplete or pending payments over the same window.

Why our number may differ:

Reason	Direction	Why
Age sub-count	Ours narrower on alert	Ecwid shows all awaiting-payment orders; our alert keys specifically on those aged over 24h, so the alert figure is a subset of Ecwid’s total.
Manual payment reconciliation	Theirs higher	Bank-transfer and manual orders stay awaiting-payment until the merchant marks them paid; if you reconcile in batches, Ecwid carries them until you act.
Time zone	Boundary on age	Ecwid timestamps in store-local time; we compute the 24h age in UTC. The order’s absolute age is the same, but edge cases near the 24h mark can classify differently.
Cancelled-out orders	Either	Ecwid may auto-expire some abandoned orders; until it does, they remain in the count on both sides.
Sync lag	Marginal	Webhook-driven; an order that just paid may briefly still show here until the order.paid event lands.

Internal identity:

ecwid_awaiting_payment_orders = COUNT(orders WHERE paymentStatus = AWAITING_PAYMENT), with the alert on the subset where now - created_at > 24h.

Known limitations / merchant FAQs

Is a few awaiting-payment orders a problem? No. A handful of fresh awaiting-payment orders is normal checkout noise, especially if you accept PayPal or manual methods that take a moment to clear. The signal is in aged orders (over 24h) and in the count climbing well above your usual baseline.

Does this include abandoned carts? No. A cart that never reached the order step has no order object, so it is not counted here. This card only counts orders that were created but not paid. Pure cart abandonment is a separate funnel concern.

Why does PayPal sometimes leave orders here? PayPal can place a payment in a pending or under-review state, which leaves the Ecwid order in AWAITING_PAYMENT until PayPal confirms. These almost always clear inside a day. If PayPal pending orders are piling up beyond 24h, check the PayPal dashboard for a hold or review.

I take bank transfer and mark orders paid manually. Will they always show here? Yes, until you mark them paid in Ecwid. If you reconcile transfers weekly, those orders will sit in this count all week. That is expected; consider whether the 24h alert threshold suits a manual-payment workflow or whether you want it raised.

My count spiked overnight. What do I check first? Place a live test order and try to pay. If you cannot complete payment, the gateway or the widget embed is the cause. Then check Stripe and PayPal for declines or account holds, and confirm the host site loaded the widget without errors.

Can a broken host site cause this? Yes. If a theme or plugin change on the WordPress, Wix, or Webflow site breaks the checkout script, customers can still create an order but cannot submit payment, which lands them here. Reverting the recent host-site change often clears it.

Does this card auto-cancel stuck orders? No. The card is informational. Ecwid may auto-expire some abandoned orders on its own schedule, but Vortex IQ does not modify order state. You decide whether to nudge the customer to complete payment or cancel.

How fresh is the count? It is a real-time card, refreshed each polling cycle and on the relevant webhooks. An order leaves the count within moments of reaching PAID or CANCELLED.

Should I email customers with stuck orders? Often yes. A short “we noticed your order did not complete, here is a link to finish” message recovers a meaningful share of aged awaiting-payment orders, provided the underlying gateway issue is fixed first. Sending the nudge while the gateway is still broken just frustrates the customer.

---

Tracked live in Vortex IQ Nerve Centre

Awaiting Payment Orders is one of hundreds of KPI pulses Vortex IQ tracks across Ecwid and 70+ other ecommerce connectors. Nerve Centre runs the detection layer; Vortex Mind investigates the cause when something moves; Ask Viq lets you interrogate any number in plain English.

Start for free or book a demo to see this metric running on your own data.