> ## Documentation Index > Fetch the complete documentation index at: https://docs.vortexiq.ai/llms.txt > Use this file to discover all available pages before exploring further. # 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. **Card class:** [Non-Hero](/nerve-centre/overview#card-classes-explained) • **Category:** [Ecommerce Platform](/nerve-centre/connectors#connectors-by-type) > 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 | ```text theme={null} 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](/nerve-centre/kpi-cards/ecwid/total-orders) | The completed side. | Awaiting-payment up + paid orders down = a gateway or checkout failure, not demand. | | [Pending Orders](/nerve-centre/kpi-cards/ecwid/pending-orders) | The next stage. | Once payment clears, orders move to pending; watch the handoff between the two. | | [Conversion Rate](/nerve-centre/kpi-cards/ecwid/conversion-rate) | Funnel context. | CR dropping while awaiting-payment rises confirms buyers are stalling at the pay step. | | [Cancellation Rate](/nerve-centre/kpi-cards/ecwid/cancellation-rate) | The cleanup. | Aged awaiting-payment orders often end as cancellations; a rise here foreshadows a cancellation bump. | | [Total Revenue](/nerve-centre/kpi-cards/ecwid/total-revenue) | The money lost. | Awaiting-payment orders are revenue at risk; a stuck pile predicts a revenue dip. | | [Order Volume](/nerve-centre/kpi-cards/ecwid/order-volume) | Demand check. | Volume steady but paid orders falling = a payment problem, not a traffic problem. | | [Revenue at Risk](/nerve-centre/kpi-cards/ecwid/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](/nerve-centre/kpi-cards/ecwid/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](https://app.vortexiq.ai/login) or [book a demo](https://www.vortexiq.ai/contact-us) to see this metric running on your own data.