How to import NCR customer loyalty points into rewards plugins

NCR Retail Online was an ecommerce software platform for connecting online stores with retail inventory and business systems. The platform has now been discontinued, so Australian merchants moving to Magento, WooCommerce, or another NCR Counterpoint partner solution need a deliberate approach to customer data and reward balances. Importing NCR’s customer loyalty points into points and rewards plugins is therefore both a technical task and a promise that customers keep the value they earned.

The main risk is treating loyalty as a single number. A balance may sit in a CRM, point-of-sale system, ecommerce database, or third-party loyalty service, while each store could apply different earning and redemption rules. Copying totals without their history can duplicate points, resurrect expired balances, or make a customer dispute impossible to resolve.

A sound migration begins with the system that owns the authoritative ledger, exports it into a mapped format, tests the load, and then reconciles source balances with the destination plugin. Depending on the extension, you may import a current balance, a detailed transaction history, or both. It would be risky to assume every points and rewards plugin accepts the same file or API.

Australian teams also need to account for GST-inclusive pricing, the Privacy Act 1988 and Australian Privacy Principles, and the Australian habit of calling reward points “loyalty dollars” even when they are not redeemable as cash. Customer identifiers commonly include +61 mobile numbers and state-specific postcodes, so normalisation matters before records are joined.

Locate the real source of loyalty data

Start with an ownership audit rather than the ecommerce storefront. Ask NCR, the Counterpoint partner, and internal teams to identify where a customer’s points are created, redeemed, expired, and adjusted. Check whether the store merely displays loyalty balances through an integration. If several databases contain values, nominate one source of truth and document how often it changes.

Map source customers to destination accounts using the customer ID first, followed by verified email or mobile number. Do not merge records solely because names match: “Sam Smith” can appear more than once. Preserve the NCR customer reference, migration date, original tier, and match method so support staff in Melbourne or Brisbane can trace every imported balance.

Build a migration-ready points ledger

Request an export that includes the current balance, lifetime earned and redeemed amounts, tier, expiry date, and a row-level history of earn, redeem, refund, reversal, expiry, and manual adjustment transactions. Include transaction dates, order references, and reasons. These fields let the destination calculate an auditable balance instead of accepting an unexplained total.

Decide whether to import historical events or only the opening balance. Importing events preserves member tenure, promotional bonuses, and earning-rate changes, but it depends on the plugin’s capabilities. A balance import is simpler, yet it needs a clear cut-off date and a retained export to prevent old orders from earning points again. Fractional points, point caps, expiry rules, and the tax treatment of redeemed rewards should be documented before rounding or conversion is applied.

Map the ledger to the rewards plugin

For WooCommerce and Magento, inspect the installed extension’s importer, CSV template, field restrictions, and API limits. Map customer identity, points type, quantity, status, and timestamp into its expected structure. Do not force an NCR export into a generic template or insert records directly into plugin tables without confirming the supported import method.

Recreate earning logic in the destination, including reward rates, exclusions, tier multipliers, caps, and redemption thresholds. Test how the plugin handles refunds and whether it allows points to be applied to shipping. For recorded training, video conversion steps can help turn legacy walkthroughs into web-friendly clips for store and service teams.

Protect customer data during the transfer

Keep the transfer proportionate. A loyalty export needs identifiers and point history, not card numbers, CVVs, passwords, or unrestricted birth dates. Apply the Australian Privacy Principles, document the new purpose and retention period, and restrict access to authorised staff. Promotional point campaigns also need to respect the Spam Act 2003 and existing consent records.

NCR’s archived PCI compliance guidance explains why payment data should be separated from migration files and why access, logging, and vulnerability management still matter after an NCR-to-Magento move. Loyalty points are not card data, but they become more sensitive when combined with purchasing history. Encrypt files in transit and at rest, use a named transfer account, and delete temporary exports under a documented schedule.

Pilot, reconcile, and release carefully

Run the first load into a staging copy and reconcile it against the authoritative ledger. Compare total liabilities, customer counts, negative balances, duplicate accounts, expiry dates, and a sample of transactions by tier. Pilot with a small group before scheduling a wider Australian release, accounting for the different trading hours of Perth and the eastern states.

Before the final run, use these controls:

• Archive a read-only source export, its checksum, and the field map before transforming any data.
• Normalise customer identities, retain source IDs, and flag ambiguous matches for manual review.
• Run the import in staging, reconcile totals and samples, and repeat the test after every mapping change.
• Use a staged release with backups, a rollback point, and a batch window that suits Australian operating hours.
• Record plugin rules, expiry settings, and support procedures so every team handles points consistently.

Once the checks pass, schedule the production load during a controlled window and prevent normal customer activity from creating duplicate rewards. Compare post-import balances with the approved source totals, investigate every material variance, and retain a rollback package until the first reconciliation and customer-support review are complete.

Equip support teams and watch adoption

Train customer-service teams to explain point conversions, expiry, refunds, and tier changes in plain Australian English. A script might acknowledge that a customer noticed “their loyalty dollars disappeared” while avoiding any promise that points equal cash. Keep escalation paths for mismatched balances and retain screenshots or transaction IDs with each case.

Track point liability, earn-to-redeem ratios, redemption by tier, average order value, and support contacts before and after migration. NCR’s advice on replacing built-in reporting with modern analytics tools can help merchants compare legacy NCR reports with current WooCommerce or Magento dashboards. Validate event definitions before treating a sharp change in redemption as customer behaviour rather than a reporting fault.

Preserve a trustworthy loyalty history

Keep the original export, field mapping, validation results, plugin configuration, and release logs together for the period required by business, contractual, and tax rules. Document what was imported, which balances were excluded, and how future refunds or expiries will work. Periodic reconciliation will reveal duplicates caused by customer creation flows or a re-import that was not designed to run more than once without duplicating value.

The essential thing to remember is that a successful loyalty migration transfers both value and trust: every balance must reconcile, every earning rule must be clear, and every customer should be able to see why their points moved.