Migrating NCR credit limits to a card vault

Migrating NCR’s customer credit limits to a credit card gateway vault requires more than moving a customer table and pointing the storefront at another endpoint. NCR Retail Online automated ecommerce selling while synchronising inventory and business data with Counterpoint. Since the product has been discontinued, retailers are moving to platforms such as Magento or WooCommerce through NCR Counterpoint partners, carrying credit accounts and stored payment arrangements with them.

The key distinction is that a customer credit limit and a vaulted card do different jobs. The limit belongs in the commerce or credit ledger; the gateway vault stores tokenised credentials. The useful outcome is a joined customer experience: credit is applied first, and any authorised remainder is charged to a saved card without exposing card numbers.

Australian conditions make that design concrete. Accounts are priced in Australian dollars, the GST is 10 per cent, and shoppers expect eftpos as well as Visa and Mastercard at checkout. They also expect Buy Now, Pay Later services such as Afterpay, humm and PayPal, which need separate treatment from account credit and card-on-file payments.

The migration should preserve trust rather than simply make records appear in the new database. In plain Australian language, a customer wants to top up an account, sort out a failed payment and put the balance on the saved card without being charged twice. That continuity depends on clear mappings, controlled reconciliation and tested reversals.

Separate credit limits from card credentials

Start by naming the authoritative record. For each customer, the new platform should retain the credit limit, posted balance, reserved amount for open orders and calculated available credit. Checkout must test the complete order, including shipping and GST, against available credit. A gateway may provide risk controls, but it should not become the accounting source for customer debt.

Where a customer uses both credit and a card, define the sequence before coding. Common behaviour is to reserve account credit, place the remaining amount through the vault, and release the reservation if the card is declined, cancelled or returned. The final rule must also handle refunds, because a returned item can restore credit even when the original payment was split.

Keep the data model separated. Customer identity, billing terms and exposure remain in the platform; gateway customer identifiers, payment tokens and recurring-payment permissions remain in the vault integration. This division reduces confusion during audits and allows a gateway change without rebuilding the credit ledger.

Map customers, balances and account roles

Create a source-to-target specification before extracting anything. Include customer and account numbers, contact details, credit tiers, terms, status, limits, current balances, open invoices, outstanding orders and authorised account roles. Map legacy status values such as suspended, probation and approved to explicit platform states instead of relying on free-text notes.

Opening balances require particular care. A limit is an ongoing rule, whereas the available balance changes with every order and invoice. Migrate the agreed opening exposure and preserve enough history to explain it; do not freeze a stale balance and assume it is permanent. Where two NCR records may represent one customer, resolve the duplicate before assigning a gateway customer ID, because merging balances after tokenisation creates a difficult correction problem.

Build a reference table that connects the old customer, the new customer account and the vault customer. Record every transformation, operator and timestamp. This evidence supports exception handling when a payment lands against the wrong account and gives finance teams a trace from a new order back to the authorised NCR balance.

Move credentials into the gateway vault

Stored card data should move through a PCI DSS-aligned tokenisation process, normally using the gateway’s hosted fields or application programming interface. Raw primary account numbers and card verification values should not be copied into ordinary migration files, spreadsheets or staging databases. If a legacy extract contains them, restrict access, document the authorised purpose and follow the gateway’s secure transfer or re-tokenisation method.

Tokens are usually tied to the provider that created them. If the destination gateway differs, expect to re-tokenise through an approved flow or ask customers to save their card again; do not assume a token can be imported into another vault. Store only the new vault identifier and the minimum display data, such as the last four digits and brand, alongside the customer mapping.

Check the Australian payment settings before the first live request. Confirm card-on-file consent, recurring transaction treatment, authentication requirements, refund routing and failed-payment retries. Privacy obligations under the Privacy Act 1988 and the Australian Privacy Principles still apply to the surrounding customer profile, even when the card itself has been tokenised.

Test the migration with Australian shopping patterns

User acceptance testing should combine the old NCR behaviour with realistic Australian orders. Teams can use the site’s user acceptance testing as a starting point for business sign-off, then add account-credit scenarios that a generic store migration may miss. Include staff who approve accounts, service customers at the counter and reconcile end-of-day takings.

Useful test cases include:

• A $150 AUD order for a Melbourne customer with $120 available credit, paying the $30 remainder with a saved Visa card.
• A Brisbane shopper $5 above the limit, with the order declined before a card payment request is sent.
• A Sydney order placed with account credit, then cancelled, with the reserved credit released and no payment left pending.
• A Perth customer paying with an eftpos debit card in a wallet that does not support recurring use, with a clear approved fallback.

Pay attention to local operating differences without turning them into hard-coded rules. Support handoffs may cross Sydney, Melbourne, Brisbane and Perth business hours, while daylight-saving changes affect support coverage. Confirm that order timestamps, statements and gateway events use one recorded Australian time standard, and that staff can explain a decline in terms the shopper will understand.

Reconcile orders, payments and customer accounts

Cutover needs a short, controlled maintenance window or a carefully managed dual-run. Take a final NCR snapshot, capture any later changes, and stop writes only where duplicate orders or balance movements could occur. Make each imported request idempotent so a retry cannot create a second customer, order or payment. The WooCommerce switch case study provides a useful reference for planning platform-specific checks.

Reconcile these checkpoints before the old path is retired:

• Customer counts and mappings, including merged, suppressed and inactive accounts.
• Opening credit exposure, open invoices and the balance assigned to each customer.
• Vault customer IDs and token references, with every active token resolving to one platform account.
• Order, tax, refund and settlement totals in AUD, with GST totals matching source records.

Rollback must account for both data and money. A restored connection is not enough if payments were already taken in the new gateway; identify which system owns each transaction and prevent a replay. After sign-off, keep a read-only archive of the source mapping for the agreed retention period, then close access to unnecessary extracts.

Keep governance strong after go-live

Day-to-day ownership should sit with named teams rather than the migration project. The retail finance team owns limits and reconciliation, ecommerce operations owns checkout exceptions, and the payment team owns vault configuration and gateway incidents. Review customer limits when they top up their account or request more purchasing power, with role-based approval and an audit trail.

Monitor patterns that look different after launch: declines near a limit, repeated token failures, split payments, refunds crossing tender types and mismatches between gateway settlement and the platform ledger. Customer support scripts should use plain language: which credit was applied, which card amount failed and what the shopper can do next. This matters when a team in another state takes over the case.

Secure migration is an ongoing operating model, not a one-off data transfer. Tokens need expiry and re-authorisation rules, access to mappings must be reviewed, and old card data must be securely disposed of when obligations permit. The durable point to remember is simple: keep credit decisions in the commerce platform, keep card credentials tokenised in the vault, and prove that every balance and payment reference agrees before the legacy connection is switched off.