When something looks wrong

iVendNext WooCommerce connector · version 2.1.0.136 · checked 2026-10-29

This page covers what is particular to the WooCommerce connector. Each entry says what you see, what it means, what to do and when to call support. For a symptom every connector shares, read the Integration Core page Something looks wrong first. It covers a connection that has not reported, a record that reads Unverified, Failed or Needs a decision, a missing Retry button and an alert that does not arrive. The states and words are defined once, in What each state means.

Never describe a record that reads Cannot tell if it arrived as failed or pending. It means iVendNext cannot tell whether the record reached the store. Retrying it could move the same money twice.

Find your symptom

An online order is not in iVendNext

What you see. A shopper placed an order on the store, and no Sales Order or Sales Invoice in iVendNext carries its number.

What it means. One of six things. Check them in this order.

What to do.

1. Was the order changed before Import Orders From? Those orders are never imported.
2. Is its status one of Imported Order Statuses? The default is processing,completed. If not, the order is listed in Orders Not Imported (History) with the reason.
3. Is it blocked? Look at the Waiting card on the Integrations Hub: Waiting on a setup change, Held behind an unknown attempt and In progress. The usual reasons are an unmapped payment method, a product that is not linked, a missing account, a tax rate iVendNext never sent, or an order number this customer already has on a document. Another storefront's document with the same number blocks the order only on a Sales Order connection, or when it has the same day and the same total. The row reason says which.
   • If it is the same order and the other store will not report it again, use Record Links, then Link manually, to link this order to the named document. That needs write access to the document, so an accounts user may have to do it. Never do this while both stores still report the order, because each store's later refunds would then credit the customer twice.
   • If it is not the same order, change the Customer's PO on the other document. You can edit it after submit. The next check imports this order.
   • Never tick Allow multiple Sales Orders against a Customer's Purchase Order to clear one. It switches off every duplicate check for the whole site.
4. Is the scheduled check running? The connection form says so when it is late. See The scheduled check has never run, or is late.
5. Does Live Updates read Disabled? Orders still arrive through the check every Check Every (minutes), 5 by default, and through the daily re-read of the last 48 hours. Press Register Webhooks in the Store menu.
6. Is it waiting for a person? A Needs Decision row that says to book it by hand needs you to act. An order in a status the connector does not know, usually from a plugin, closes as Failed and names the status.

When to call support. Send the iVendNext Integrations product team the store order number (or product SKU), the connection name, and the row reason copied exactly.

A record is waiting on a setup change

What you see. A row under the Waiting card on the Integrations Hub, in Waiting on a setup change. In its own state, the record reads Blocked. Many rows waiting together are explained in Core's Many records are waiting.

What it means. The row reason names what is missing: a product not on the store, an unmapped payment method, a missing price or an order number already used. Where a field on the connection fixes it, Open the fix scrolls the connection to that field. An account field also needs read access to Account. Without it, the screen says Not permitted when the field takes focus.

What to do. Fix what the reason names. The connector tests every check again and moves the row on by itself. An alert fires once a row has waited longer than Alert If Waiting Over (minutes), 1,440 by default.

One reason is different, and the Hub lists it under its own link, Held behind an unknown attempt: "kept, and not re-queued yet: an earlier attempt at this record may already have reached the other system". That is about money. Wait for the status check to settle it. Do not force it.

When to call support. If the reason names nothing you can act on, send the same details as for an order that is missing.

A record needs a decision

What you see. A record reads Needs Decision, or Needs a decision on the Hub.

What it means. Core's Needs a decision explains the state and the Keep iVendNext Version button. Here the reason says what the store did and what to do by hand. A refund row, for example, asks "Paid out? Accounts + Integration Manager: return it on …".

What to do. Do what the reason asks, on the store or in the books. Then press Keep iVendNext Version. That records that your version stands and who decided. The question comes back when the store writes a new note on the order, when the store's notes cannot be read, when the question itself changes, and after a Re-check. Keep closes the record. It does not do what the reason asks. If the store version is right, correct it on the store and let a fresh change arrive. For a store cancellation, first check that the order is still canceled on the store. Core's A decision keeps coming back covers the rest.

When to call support. If the reason cannot be acted on, or the same decision returns after you kept it with nothing changed on the store.

The store refused the connection key

What you see. Records are set aside (in the record's own state, Deferred). The connection says the store refused the sign-in, and the setup form lists it. Core describes the shared words in The other system refused the sign-in.

What it means. The store answered 401 to the REST key, so the change is set aside and the check stops. Each later check spends one call to find out whether the key works yet. A key without write permission is refused with 403, and the check stops the same way, with at most one Failed row for each check.

What to do. Fix the key. Follow Replace the REST key, then press Retry on a Failed row. Once the store accepts a call, iVendNext picks up what was set aside, 500 records for each scheduled check. At the default of 5 minutes that is about 6,000 records an hour. The changes are kept while they wait. Alerts come after 12 hours. A key refused on a write can read wrong for up to an hour while orders are already crossing. Look for fresh Applied rows on Integration Activity before you escalate.

When to call support. If the new key is refused again, or the setup form still says refused an hour after orders resumed.

The store does not answer

What you see. The connection says the store cannot be reached, and changes are not arriving.

What it means. Nothing is recorded as lost, and no position moves. Changes go once the store answers. A store that answers 429 or 408 (throttling) stops the check too, and iVendNext retries the one attempt. Core describes the shared words in The other system cannot be reached.

What to do. Ask the store owner whether the store is up and whether its address changed. If the store answers every call with 404 "no route", check that the WooCommerce plugin is active and that permalinks and rewrite rules are intact. The connector reads that answer as an outage, not as a deletion.

When to call support. If the store is up and answering, and the connection still says it is unreachable.

The store notifications are switched off

What you see. Live Updates reads Disabled. The setup page lists Store webhooks (Register Webhooks) as OFF on the store under To do. The Integration Manager gets an alert, "the store switched our webhooks off".

What it means. WooCommerce sends each notification once, with no retry. After seven failures in a row, it switches that notification off without telling anyone. iVendNext sees the switch-off only after it has happened. Two checks catch the missed orders: the check every Check Every (minutes), 5 by default, and a daily re-read of the last 48 hours. The 5-minute check can still miss an order among a hundred or more stamped in the same second, or one the store makes visible more than a second after its timestamp. The daily re-read books those.

What to do. Press Register Webhooks in the Store menu again. iVendNext does not turn the notifications back on by itself.

When to call support. If the notifications switch off again after you register them. The store may not be able to reach the connection Public URL.

The scheduled check has never run, or is late

What you see. The setup page lists Scheduled check has run under To do, or says the scheduled check is some minutes late.

What it means. The usual cause of "never run" is a site whose time zone was set after its apps were installed. Its first scheduled run can then be hours away. "Late" means the scheduled job is slow or stopped, or no background worker finishes it.

What to do. A System Manager checks the scheduled job drive.woocommerce_every_five_minutes and that the background workers of the site are running. A connection runs one check at a time, using a database lock. A worker whose database session hung keeps that lock until the database timeout, which is 8 hours by default. Support finds and ends that session. Most changes catch up when the check runs again.

When to call support. If the jobs are running and the form still says the check is late.

The connection says the store address or keys changed

What you see. The connection alerts "Press Test Connection: the store address or keys changed", and nothing is sent to the store.

What it means. Someone changed the Store URL or a key since Test Connection last proved the store. Every store call is refused, and the scheduled check does nothing. Orders that the store notifications deliver still import.

What to do. Press Test Connection. If the store answers as the same store, the connection runs again at the next check. If it answers as another store, iVendNext refuses it and the connection stays stopped. Create a new connection for that store.

When to call support. If Test Connection succeeds and nothing is sent at the next check.

A delivery from another site was refused

What you see. The bell tells a System Manager that a delivery from another site was refused, and names the site. Or a test copy of the store exists.

What it means. A delivery signed with this connection's secret came from a site that is not the address the store reports (Store Address Reported). Either a copy of the store is sending its test orders, or the store moved, or the Store URL is an alias of it. A restored or copied WordPress keeps the iVendNext notifications and their secret. Nothing from a copy was recorded. A copy that still reports the address of the live store is not caught by this check.

What to do. For a copy, delete the iVendNext notifications on every test copy, under WooCommerce, Settings, Advanced, Webhooks. Never point a live connection at a test copy. For a moved store or an alias, a System Manager sets Store URL to the sending address and presses Test Connection. Until then the live feed is refused, but the scheduled checks still read the store's orders. A store that answers on several addresses can be refused whichever one is recorded. A System Manager can then switch Refuse Deliveries From Other Sites off. A copy's orders are then booked, so delete the notifications on every copy.

When to call support. If the refusal repeats after the Store URL matches the sending address.

A collect order waits for its pickup location

What you see. An order a shopper collects from a shop is Blocked with a message that names the location, says no warehouse maps that pickup location, and tells you to add it under Orders From The Store, Pickup Location Mapping. The connection To do list names the location too.

What it means. The shopper chose a pickup location that no row of Pickup Location Mapping names. Nothing was booked, so no shop stock moved.

What to do.

1. On the connection, open Orders From The Store, then Pickup Location Mapping. Add the location name as the message shows it, and the warehouse of the shop that hands the order over. The warehouse must belong to this connection's company, have stock (not be a group) and be enabled.
2. Save. The order comes in at the next check by itself. A location renamed on the store is a new name here, so add it too.
3. A warehouse disabled after you mapped it makes its orders wait the same way. Enable it, or map the location to another warehouse.
4. An order that names no location, or is collected in two places or part shipped, cannot be routed by any row. It waits for a person: book it by hand from the store order, then use Record Links, Link manually.

Never map a location to the fulfillment warehouse just to make it pass, unless that shop really hands the order over. Otherwise the stock of the shop that did will stay wrong.

When to call support. If the order still waits after a row maps the exact name to an enabled warehouse of the company that has stock.

An order waits for a store tax rate

What you see. An order is Blocked with a message that begins "tax rate #N" and a label, says the rate has no Tax Rule, and ends "setup guide T1". This entry is that guide.

What it means. The order carries a tax rate that iVendNext never sent. The fix depends on the tax class of the rate on the store. There are three ways out.

What to do. Pick the one that fits.

1. The rate belongs in the standard class of the store. Make a Tax Rule with Use for Shopping Cart, on a one-row template at the same rate. It must match the country, state, postcode and city of the rate. iVendNext adopts the rate only where the store has it at priority 1. A different rate or priority creates a second rate instead.
2. The store keeps the rate in another class. In Tax Class Mapping on this connection, map the Item Tax Template that overrides this jurisdiction's tax account at the same rate. A template that names another account sends the standard rate instead.
3. You want to keep the store's own rate. Make a Tax Rule for it in a Tax Category of its own, so desk sales keep their tax, with Use for Shopping Cart off. Then use Record Links, Link manually, with Record Type Tax Rate, the rate number exactly as the store has it, and iVendNext Record Type Tax Rule. Give that Tax Rule a one-row template, because a hand link to a template with several rows is refused. iVendNext never sends a rate linked this way back to the store. If that rate sits under one of the multi-row storefront rules of iVendNext (a narrower address inside a wider one), the store also charges the rows 2 and up of that rule. Add 0.0000 rates at those priorities for that address yourself, or the shopper pays too much tax.

If the message says "book it by hand" before "setup guide T1", none of the three ways works. It means the store rate belongs to a tax row since deleted from its template, or the first row of the template now has another rate. Book the order by hand from the store order, then use Record Links, Link manually, with Record Type Order. For a refund, book a return against the invoice and link it to the refund.

If a refund waits on this, not an order, the order is already booked. Do not book it again. Fix the rate by one of the three ways and the refund's credit note arrives by itself.

Ways 1 and 2 send the rate only if it also matches the address the store taxes on (Tax based on) and matches the store setting Prices entered with tax. Otherwise iVendNext refuses it, and the order keeps waiting. Removing the rate on the store does not release this order. It only helps later ones.

Type the link exactly. A store id typed as 6.0 or #6 never matches. To undo a wrong link, open it on Record Links and press Make inactive. The link alone may not release the order. Three further refusals can follow, and each names itself: the Tax Rule names no Sales Taxes and Charges Template, the template has several rate rows, or the tax account belongs to another company.

When to call support. If the link is made and the order still waits. Send the row reason copied exactly.

A refund waits on a Sales Order connection

What you see. A store refund is Blocked on an order on the Sales Order path. Its reason reads "waits for … invoice (no advance)" or "returns no money". Or it is Needs Decision and reads "refund to book by hand".

What it means. A refund before invoicing is paid back out of the advance, and the goods it names come off the order. Three shapes cannot be returned from the advance:

• an order with no advance, usually cash on delivery. The refund waits and is credited on the invoice of its goods once they ship;
• a refund the store stated as returning no money. It is recorded on the invoice when the order is billed;
• a refund larger than the advance still has, or one with no amount. A person books it.

What to do. Pick the case.

• Two or more invoices. Accounts and an Integration Manager credit the invoice that billed the refunded goods, as the row says.
• Cash on delivery, or "returns no money". Ship and invoice the order, and the refund arrives by itself. A cash-on-delivery order the store refunded is invoiced with its door cash not booked, so Accounts book the door cash by hand. If the goods will not ship, close the order. The refund then becomes a Needs Decision row for a person. Never book it by hand while it still waits, or the customer is refunded twice.
• Refund to book by hand. Accounts book what the row names, such as a payment entry to the customer from the account of the advance. Then press Keep iVendNext Version on the row. That records the refund as booked by hand, and iVendNext never books it itself. Where the row says "close order", close the Sales Order too, or its goods stay open to ship. Where it says "remove goods", take the refunded goods off the order.
• Goods and charges apart. The goods were billed on one invoice and the shipping or a fee on another. Credit each half on the invoice that billed it, link the notes under Record Links, then press Keep iVendNext Version.
• Goods not yet billed. The charges are on an invoice. Pay the goods back from the advance and take them off the order. Credit the charges on the invoice that billed them. Link both under Record Links, then press Keep iVendNext Version.
• The store kept some of the money. The row says "the store kept X of what it names, on its advance". That money stays on the advance. Bill it by hand when the last invoice asks.

When to call support. If the order is invoiced and the refund still waits.

An order or refund waits on a closed period

What you see. A refund, an order or its payment is Blocked with one sentence. It gives the date and what closes it: an Accounting Period, Accounts Frozen Till Date or a Period Closing Voucher.

What it means. The document is dated in a closed period. A payment dated in a year with no active Fiscal Year waits the same way.

What to do. The document arrives by itself once an accounts user reopens the period, moves the frozen date, or creates the year under Accounting, then Fiscal Year. Or set Closed Period Posting on the connection to Post in the current open period. Then it posts today, and the remarks on the document carry both dates. Two shapes differ. A payment collected at delivery whose date is closed waits on the delivery push, which stays Unverified and is checked again every few minutes. A Comment on the order says why. The shipment itself already reached the store. The second shape is a payment whose paid mark arrived together with a change that needs a decision. iVendNext does not ask again about it. Its sentence says to record the payment by hand once the period is open, and it is never booked otherwise.

When to call support. If the period is open and the row still waits.