Manage marketplace channels and original external orders

Bring one original external sale into your selling records#

Connect one exact merchant-operated WooCommerce store or an owner-supplied channel file. Map precise products, prepare a listing change, compare its before-and-after values and submit only the supported reviewed action. External orders enter an intake queue before any canonical order, invoice or warehouse reservation is created.

A channel observation, remote publication, external paid status, issued invoice, actual receipt, physical dispatch and verified provider refund are distinct facts. Each keeps its original source and permission. Unknown external effects stay unresolved until their actual result can be established.

Configure the original selling apps deliberately#

Marketplace Channels is a corporate app requiring configured Ecommerce. It never installs dependencies or carries private records, staff, licences or paid allowances from another profile. Review the established business identity, country, currency and actual selling facts in the existing setup.

Canonical adoption also requires current Invoicing configuration and financial authority. Warehouse allocation needs Inventory and an exact canonical item route. Missing prerequisites keep the dependent action unavailable. A remote collection claim does not create a Payment Gateways capture.

Choose operating access and deliberately enable new work#

The owner chooses whether only managers or explicitly granted staff may prepare work. Outbound publication and order intake have separate operating controls. Enabling either does not connect an account, approve mappings, publish listings or create invoices.

Business country is inherited from reviewed shared facts. Channel market, transaction location, original currency and content language remain separate. Country and privacy acknowledgments document a review; they cannot supply missing licences, fiscal approval or acceptable source evidence.

Compare API, reviewed file and future connector choices#

The implemented API adapter targets one exact authorized WooCommerce REST v3 store. WooCommerce is a merchant-operated storefront, not a claim that Amazon, eBay or another marketplace is connected. A reviewed file records independently obtained evidence in a closed Emnaro CSV format and never performs a provider action.

The country-aware catalogue gives contextual channel options and official eligibility links. Future connectors remain unavailable for external actions. Provider market existence, seller acceptance, destination eligibility and Emnaro adapter readiness are separate facts. Recommendations never select or install a channel automatically.

Read the actual supported country scope#

The first canonical adoption scope is ordinary domestic AU/AUD originals for reviewed registered or declared unregistered sellers, and ordinary domestic NZ/NZD originals for reviewed registered sellers, only where the current invoice and stock adapters retain every amount exactly. Other seller or currency cases, cross-border treatment, special or compound taxes and unsupported fees remain in preparation or review.

This is an implementation boundary, not a universal legal prohibition. GB, EU/EEA, US states, Canadian provinces, Saudi/Pakistani fiscal actions, UAE Arabic consumer documents and Qatar/Kuwait rules require their actual workflow review. No country acknowledgment certifies tax registration, product safety, privacy compliance or authority acceptance.

Official references: AU invoicing guidance ↗ · NZ taxable supply information ↗

Save one exact channel identity#

Name the exact store/account and review its market country, currency, cutover and ownership evidence. A reviewed file account requires its immutable actual merchant account reference; a display name or matching email does not identify the account. WooCommerce requires a public HTTPS origin and optional WordPress subdirectory. Private addresses, platform origins, embedded passwords, redirects, arbitrary paths and unsupported ports are rejected.

Configured, read access checked, paused and revoked describe connection authority. A successful read check does not establish publication, stock allocation, order acceptance or settlement. Listing and stock results retain their own observations and timestamps.

Keep credentials write-only and rotate safely#

Enter the actual authorized merchant REST key and secret only in the protected connection form. Fields clear on submission, including failures. Page props, browser history, exports and ordinary history show presence/status only. Never paste credentials or raw provider responses into reasons or evidence notes.

Rotation preserves the original store identity and unresolved history. New credentials cannot relabel another account, retry an uncertain effect or erase protected exposure. If the response was lost, check the original request before submitting another decision; empty fields do not prove the original failed.

Choose an original-order cutover and review older history#

Cutover is the deliberate boundary between newly handled channel sales and earlier records that may already exist in the business books. Enter an explicit UTC timestamp and compare the actual channel account. Rotation or reinstall does not reset stable external order identity.

Older, already fulfilled, already invoiced or ambiguous sales need duplicate/fiscal source review. Do not move cutover to bypass it. Use exact existing-order association when supported evidence establishes the original; otherwise preserve the unresolved exception.

Decide who owns the published price#

Observe-only pricing keeps the remote price as evidence. Canonical-price preparation derives selected supported listing values from the reviewed Ecommerce variant. Neither mode reprices an imported original or edits an issued invoice.

Publication shows exact before-and-after values. Unselected fields remain outside the operation. Changed source price, mapping, tax basis or connection generation requires a fresh review rather than replacing historical accepted amounts.

Choose observation or explicit Inventory allocation#

Observe-only stock never exposes warehouse quantity. Inventory allocation can protect a deliberate internal amount using the exact warehouse/item route and current Inventory authority. Positive absolute stock publication to a live WooCommerce store remains unavailable in the first release until a supported opening-exposure cutover and order-drain proof exists.

A fresh local hold cannot account for orders already accepted by the remote store before that hold. The isolated demo sandbox can exercise the positive stock flow. There is no live availability mirror or zero-oversell guarantee; unknown writes and remote overrides require review while their allocations remain protected.

Map exact canonical and observed remote identities#

Use bounded authorized searches to choose the connection, physical canonical variant and cached remote product/variation. Compare names, stable IDs, SKU, original price and observation time. Similar SKU or description is a clue, never mapping approval.

Selected records resolve independently of the current search/page. Saving creates a draft; approval freezes the compared identities. A changed source requires a fresh supported comparison. Do not substitute another item or infer company/customer access from an email domain.

Use supported simple-product and variation changes#

Existing simple products and variations support only the selected allowed fields. A variation belongs to one precise parent/variation identity; the parent is not automatically a sellable canonical variant.

The first adapter does not create variable parents or variations, replace categories/attributes, proxy images, change tax classes or delete products. Existing variation name updates are unavailable. Complete unsupported edits at the provider and refresh the original observed identity.

Retire changed mappings without erasing originals#

Retirement stops new use while preserving identities referenced by original orders, publication attempts and stock exposure. An old invoice or reservation cannot be reassigned to a replacement product.

Review a separate mapping after product replacement, SKU reuse or variation identity change. Resolve open publications and allocations against their original identity and connection generation. Editing or deleting a draft cannot bypass retained source ownership.

Prepare one new simple remote draft#

Choose one authorized physical Ecommerce variant to prepare its exact name, plain description and regular price. Preparation creates a local review first; the new remote object is a draft. Public selling requires a separately supported current review.

An ambiguous create response may mean the draft already exists. Reconcile the original remote ID or supported operation-marker evidence. An empty search result cannot prove failure, so no automatic create retry is offered.

Compare and submit one precise publication#

Compare every selected remote field with the desired value and check mapping, connection generation and review expiry. Name, plain description, regular price and status are separate selections. A prepared review does not mean the external store changed.

Confirm only the exact current review. Observed, rejected, conflict and unknown outcomes remain distinct. Live WooCommerce status=publish is unavailable when stock ownership is Inventory allocation: activating a listing could expose existing remote quantity without the missing cutover proof. Preparing a remote draft does not establish permission to activate it.

A malformed or partial response cannot establish whole-batch success. Listing changes never change original order, payment, refund or fulfilment facts.

Keep drafts and re-review changed facts#

Validation keeps nonsensitive entered values and returns to the exact bounded submitting page. Another tab changing the previous URL cannot choose the destination. Credentials clear instead of being remembered. Changed versions or review hashes need fresh deliberate comparison.

An uncertain submission keeps its original opaque request reference. Check its receipt before changing details or starting another decision. A later validation failure cannot prove an earlier unknown effect failed. Compare the current record in a new tab without overwriting your draft.

Fetch bounded original order windows deliberately#

Choose explicit UTC start/end timestamps, a window no longer than 24 hours and a bounded page. Observations preserve external identity, modification time and provenance. Viewing a GET page never triggers a provider request.

Repeated or overlapping fetches reuse the stable account/order identity and retain immutable revisions. Page saturation or schema/clock problems are exceptions, not proof of complete catch-up. Refresh an exact original order when current evidence is needed.

Review observations before creating business records#

An intake row shows what the provider or owner file reported. Compare external status, reported collection, restricted customer view, original total, observation time and existing canonical claim separately. Processing/completed status does not automatically create an invoice.

Choose the actual authorized billing customer, every approved exact product mapping and a supported delivery method. Unsupported, unmapped, already externally fulfilled or fiscally ambiguous originals stay in review. Owner confirmation does not bypass exact-source checks.

Preserve exact discounts, freight and tax#

Compare original line subtotal, discount, tax, quantity, freight and final total in the original currency exponent. The original is never repriced from the current catalogue. Adoption requires exact supported canonical decimal arithmetic without balancing lines or silent rounding.

Unknown tax treatment, unsupported fees, inconsistent totals or unrepresentable allocations remain exceptions. Correct the actual source through its owner where appropriate, then review a new observation. Previously accepted originals retain their historical facts.

Use an existing supported delivery method#

The first adoption scope uses an active flat-delivery method with matching original business/country facts. Original freight and tax remain source amounts rather than today’s method price. Choose the exact existing method; do not invent a delivery mapping.

Pickup remains unavailable until actual collection-site facts have a separately supported review. A merchant address is not automatically a pickup site. Missing destination, incompatible freight or unsupported delivery treatment stays in review.

Create one exact canonical original under current owner authority#

A current owner/administrator can adopt a representable original through canonical Ecommerce, Invoicing and applicable Inventory services. The source records the actual import actor, customer, mappings, delivery, country readiness and original amounts.

The result is one original order/document/reservation with ordinary guest access disabled for this externally managed sale. Reported paid status never settles it. Imported invoice terms stay blank because the original external agreement has not been captured; the current retail policy is not inserted as accepted external terms. Replay retains the original, and later changes require reconciliation.

Associate an established existing original safely#

Use association only when exact evidence identifies the already recorded canonical sale. Compare customer, original amounts/currency and immutable source ownership. Similar names, emails or totals alone cannot establish the relationship.

Association creates no new invoice, payment or stock movement. If evidence cannot establish the original, keep the exception unresolved. Do not create duplicate orders with the intention of deleting one later; financial and stock corrections have their own source rules.

Separate reported collection from actual receipt#

External paid, refunded and payment-method values are observations. Canonical unpaid/partially paid/paid/credited follows the actual Invoicing ledger. The initial channel adapter does not create hosted collection, gateway capture, settlement or net-payout accounting.

A currently authorized financial user records a genuine outside receipt through Invoicing with actual amount, currency, method and evidence. Credit, cancellation, reversal and provider refund retain distinct meaning. Notes or sandbox outcomes cannot establish real settlement.

Follow physical and financial corrections in original apps#

Dispatch through the original Ecommerce/Inventory/Shipping workflow. A refreshed external fulfilled status cannot dispatch the same stock again. Physical return, restocking, financial credit and provider refund remain distinct original facts.

Handle partial fulfilment and correction in the source records. Never release protected stock on unknown payment/provider outcomes or claim refunded funds from a cancellation note. Source ownership survives app disablement and retains the appropriate recovery path.

Review internal allocations and supported stock actions#

Choose an approved Inventory-backed mapping, bounded internal quantity and nonsecret reason. Review the additional hold and prior unresolved exposure; if safe available quantity is not established, it is explicitly unavailable. Observation, internal exclusive allocation and exact original-order import remain useful without positive live stock publication.

Positive live WooCommerce stock PUT remains unavailable pending supported opening-exposure cutover and order-drain proof. Reserving fresh internal stock alone cannot cover previously accepted remote orders. The isolated sandbox supports the positive review flow; there is no live rolling mirror, automatic top-up or claim that overselling has been eliminated.

Supported original-order consumption retains parent, remainder and canonical order reservation history. Shared inventory items and aliased variants cannot multiply a protected allocation.

Quiesce new exposure without treating zero as release#

Quiesce submits one exact supported zero-stock action for the original mapped object. Its actual outcome still needs observation and reconciliation. Unknown zero outcomes retain the original allocation.

A supported zero request can stop new remote exposure, but one zero read does not prove there were no concurrent sales, later edits or pending orders. Bounded intake observations do not establish the missing complete live cutover/drain proof. Empty pages, app uninstall or owner checkboxes cannot establish closure or release a protected allocation.

Release only genuinely closed exposure#

Release review compares original zero evidence, remaining hold, intake and canonical obligations. Live hold release remains unavailable without genuine supported closure proof; a zero write, fresh hold, private evidence reference or owner acknowledgment cannot supply it. Keep protection while actual live obligations are unresolved.

The isolated sandbox can demonstrate local closure/release using fictional evidence. That result is not production approval. Keep live allocation protected while resolving genuine external uncertainty through the merchant/provider workflow.

Resolve the specific original issue without generic retry#

The queue distinguishes unmapped identity, changed external orders, incompatible tax/totals, cutover duplicates, protected stock, revoked access and unknown submissions. Open the exact original record and follow its permitted next action.

Unknown writes never become a general retry button. An acknowledgment cannot rewrite finance, release stock, dispatch twice or manufacture provider success. Keep unavailable resolution visible until actual missing evidence or work exists.

Grant precise staff responsibilities#

Owners/admins grant explicit catalogue viewing, listing preparation/publication, original-order viewing or order-preparation permissions. These remain within current membership and source app permissions. Ordinary viewers cannot write; financial adoption, protected stock and retained recovery remain owner work.

Routes, services, jobs, selectors, imports and exports recheck workspace, licence, quota and exact grant. Offboarding removes authority; rejoining does not silently restore a grant. Selected customer or matching email never establishes external buyer or staff access.

Keep customer data purpose-bound#

Only current commercial/source permission reveals buyer identity, address and original collection information. Catalogue-only staff receive safe projections. Review actual collection purpose, notice, recipients, overseas disclosure and retention. Imports, purchases and invoices never imply marketing consent.

NZ indirect collection requires the current IPP3A assessment, effective 1 May 2026. Applicable Australian APP, UK/EU and other local rules need actual scope review. Do not paste sensitive records into broad notes; retain only necessary authorized evidence.

Official references: NZ privacy principles and IPP3A ↗ · Australian Privacy Principles ↗

Validate a scoped sample and compare the exact preview#

Download the mapping or intake sample, use UTF-8 and preserve IDs as text and money as exact original decimals. Multi-line orders retain one identity and unique remote line IDs. Duplicate headers or line identities are rejected.

Validation reports row/field errors before commit. Review the exact protected preview token/hash; changed content or source facts require a new preview. Files cannot manufacture accepted originals, payments, stock issues or observed publication/provider outcomes.

Retrieve permitted records for spreadsheet work#

Exports use current authorized mapping, intake or case scope and remain bounded. Import CSV into Excel with external IDs as text to preserve leading zeros and long references. Currency/exponent are explicit.

Formula-active cells are neutralized. An export is a business report, not an authority filing or an override for invoices, stock, payment or provider truth. Use paged supported exports instead of unrestricted data access.

Read original decisions and safe evidence summaries#

History retains actual actor, original subject/version, action, time and permitted reason. Credentials, raw provider responses, guest tokens and unrelated customer source are not ordinary history fields.

New observations preserve earlier originals. History/search/export retain the current audience scope. Catalogue access cannot disclose customer details through history, counts or indirect summaries after commercial access is revoked.

Pause new actions while retaining obligations#

Pause stops fresh channel authority without deleting originals or declaring remote listings, orders, holds, payments or refunds cancelled. Revoke removes new connection authority. Each requires current version, deliberate confirmation and a reason.

Old tabs, credential generations or reinstalls cannot revive retired access or relabel an unresolved account. Review current sources before future enablement. Retained owner recovery remains separate.

Use retained owner recovery after normal app access ends#

The dedicated page remains scoped to current owner/admin and active workspace/demo lifetime. It shows retained connections, protected exposures, original order links and cases without restoring fresh authoring or publication.

Current source permission still governs customer/money and original invoice/stock actions. Retained pause/revoke affects new authority only. Live release requires genuine closure. Removing the app never erases original source ownership or releases warehouse obligations.

Practice in the isolated local sandbox#

The isolated demo uses a fictional local sandbox store or reviewed temporary owner files; use fictional customer data. Live WooCommerce credentials remain unavailable in demo. The sandbox supports positive stock-publication practice, while local file imports remain recorded evidence with no external provider action.

Synchronous expiry and cleanup rules apply. Sandbox observations cannot settle production money, create entitlements or prove provider/government readiness. Sandbox orders in a production workspace remain preparation and cannot create a production invoice. Live stock cutover and release limits are not removed by a successful demo.

Keep the original and follow its next permitted action#

Read the exact unavailable reason: prerequisite, grant, country, source version or missing evidence. Correct the original setup/source issue and prepare a fresh review. Ordinary configuration uses protected owner/admin workflows, not code edits or keys pasted into chat.

For lost responses, retain the request reference and check its receipt. Reconcile unknown effects on their original object. Preserve unsupported original money rather than repricing it. If an export omits customer fields, review current commercial permission instead of copying another workspace’s data.