Moving NCR drop-shipping rules into a multi-vendor marketplace

NCR Retail Online was more than a storefront. It sat between an online shop and NCR's retail inventory and business management systems, and it carried a set of vendor-specific drop-shipping rules that kept orders moving: who supplied which line, who paid the freight, who owned the customer record, and who answered the phone when a parcel turned up damaged. With the product discontinued and stores being redirected to Magento or WooCommerce through NCR Counterpoint partners, the storefront is the easy half of the job. The rules are the half worth planning properly.

Those rules never lived in one tidy settings screen. They were scattered across vendor profiles, catalogue categories, product records, a couple of saved search lists and at least one spreadsheet somebody maintained by hand. Re-entering them without understanding where they came from is how a two-day handling promise quietly becomes a two-week delay, and how a vendor's returns window disappears entirely.

The Australian wrinkles sharpen the problem. Local shoppers expect Australia Post eParcel, weekend deliveries into Sydney and Melbourne, and 10% GST collected on low-value imported goods under the A$1,000 threshold. Merchants here also deal with a dense BNPL culture, the credit card surcharge ban, and freight surcharges that sting more in the Northern Territory and regional WA than they do in a capital-city warehouse. Get the local freight and tax details wrong and a rule set that hummed along for years starts leaking margin.

Where the vendor rules actually lived

NCR Retail Online held the store in front and NCR's back-office systems behind it, and the useful logic sat in the middle. A vendor profile carried the supplier code, ABN, returns address, freight account and the flag marking the vendor as drop-ship rather than stocked. A category setting marked whole ranges as vendor-supplied. Individual product records held the lead time, the pick-and-pack instruction and the notes that only that vendor really understood.

Some of the detail was never in the platform at all. Vendors published their own conditions of sale, spec sheets and warranty copy on their own sites, and the catalogue summarised them loosely. CCC Mining is a useful illustration of a supplier whose authoritative product and terms documentation lives on its own domain rather than inside a marketplace catalogue, which is exactly why these conditions have to be copied with intent rather than by accident.

None of this is technically difficult to move. It is just tedious to find, easy to overlook, and tempting to treat as boilerplate rather than as operational promises your customers will hold you to.

Auditing the rules before anything moves

Write the rules down before touching a line of configuration. Export the product list per vendor, dump the vendor profiles, and take one representative category and describe what actually happens at the counter. The kitchen accessories range is a good example: one supplier drops the whole range with a two-day handling promise, another ships flat-pack only with assembly notes attached, and a third line is stocked locally with a returns window the vendor will not honour past thirty days.

Next, find where each rule will live in the new platform's vocabulary. In WooCommerce that means vendor profile fields, shipping classes, tax classes and product meta. In Adobe Commerce Marketplace or a Webkul multi-vendor build it means seller configurations, per-seller shipping methods and separate inventory sources. A rule phrased as a spreadsheet note has to be rewritten as a field someone can actually maintain in twelve months.

Finally, list the exceptions, because exceptions are where handovers go wrong. Weekend despatch cut-offs, minimum order quantities, the vendor who insists on a residential delivery only, the freight surcharge for remote postcodes, GST handling on low-value imports, and the category where a vendor's stock is shared with the vendor's own site.

Rebuilding rules inside a multi-vendor plugin

Map deliberately rather than in bulk. With WooCommerce Multi-Vendor or Front's marketplace extension, supplier ABNs, handling times and freight accounts belong in the vendor profile; shipping classes and tax classes belong on the product; the marketplace commission and payout schedule belong in the marketplace settings. Under Adobe Commerce, the same logic lands in seller configurations and inventory sources, where each seller can hold their own shipping method and stock pool.

Then handle what has no clean home. Free shipping thresholds per vendor, vendor-funded coupons, the rule that a single order may contain only one vendor, and category-level drop-ship eligibility all need a home in a plugin-specific extension, a hook or a small custom plugin. Write that decision down, or the next person to onboard a vendor will guess.

Vendor-supplied content blocks deserve their own treatment. Spec widgets, live stock tickers and supplier-authored HTML usually arrive as a fragment of embed code. In WordPress that means a shortcode in a protected vendor meta field, and there is a clear pattern to follow if you have never done it: a worked guide to embedding a vendor widget walks through the shortcode wrapper, the preview in the editor and the safety checks that keep vendor markup out of your core catalogue. Keep that code out of product descriptions, where it would be wiped the first time a category is re-imported.

Payments, stored cards and vendor settlement

Payment data is the part to be careful with. Read the NCR guidance on stored payment methods before you export anything, and resist the urge to move card records as rows in a table.

The workable path is to re-issue tokens in the gateway, re-issue stored credentials against the new platform's customer IDs where the gateway supports it, and keep cardholder data out of the plugin database entirely. If a vendor was previously authorised to charge on behalf of the marketplace, that authorisation needs to be re-established in the new gateway, not copied across as a reference number.

Settlement needs its own reconciliation. In a multi-vendor setup the marketplace usually holds the funds and splits the vendor's share, so your old NCR vendor statements and the new payout reports will not line up on timing or fees. Local payment habits add a layer: Afterpay and Klarna splits, BPAY and eNets for trade customers, and the surcharge rules that keep credit card fees off Australian consumers. Vendors who quoted prices assuming an old fee structure will notice the difference.

Carrying the catalogue and its quirks across

Categories, attributes, bundles and imagery transfer more cleanly than people expect, provided you keep the vendor-specific oddities attached to the product rather than to the category. Take the everyday drinkware range: glassware and ceramics have weights that push them into a different Australia Post service level, breakage expectations, and packaging rules that belong to the vendor alone.

Weight and dimensions deserve the closest attention, because shipping classes drive the freight bill in both platforms. A product that shipped at 900 grams in NCR may have been padded to 1.8 kilos by the vendor's own packing rules, and that difference flows straight into the eParcel band and the rural surcharge. Stock badges, handling-time labels and the drop-ship eligibility marker all need somewhere to live, usually as product meta plus a badge rule in the plugin.

A cutover sequence that keeps orders flowing

Two weeks is usually enough to move a catalogue if the rules are documented, but only if the old store stays readable while the new one is tested. Sequence the work so that nothing has to be perfect on day one, and so that each stage tells you something about the next.

• Export vendor profiles, product records, shipping classes and tax classes, and store them in a versioned folder before the old platform is switched off.
• Rebuild two vendors as pilots, including their shipping classes and vendor meta, and place twenty test orders across both.
• Reconcile freight and GST line by line against Australia Post invoices and the old vendor statements, then correct the configuration rather than the spreadsheet.
• Move stored payment methods through a gateway-supported re-issue path, and confirm no cardholder data landed in the plugin database.
• Cut over the catalogue in category-sized batches with the old storefront still available for reference, then retire it once orders settle.

Your first week on the new platform

Expect the first three days to be spent on the marketplace configuration rather than the catalogue: vendor commission, payout schedule, shipping zones for Australian postcodes including remote surcharges, and the tax classes that decide who remits GST on low-value imported goods.

By the end of the week, the useful artefact is not the finished store. It is a vendor rules register: a document that says, for each vendor, who supplies what, who pays freight, what the handling time is, where returns land, and which platform field holds each rule.

Start there: create a test vendor for your highest-volume drop-ship partner, load five of that vendor's SKUs with their shipping classes and tax classes intact, and place a test order to confirm the freight, GST and handling time match what NCR used to produce.