Reconciling payment gateways after leaving NCR Retail Online

When an ecommerce platform is discontinued, payment reconciliation can become harder than the storefront migration itself. Orders may move to Magento or WooCommerce, while gateway records, refunds, fees, tax calculations and settlement reports remain tied to the former NCR Retail Online workflow. The result can be duplicated transactions, unexplained deposits or sales that appear in one system but not another.

A controlled reconciliation strategy gives retailers a reliable financial record during the changeover. Australian businesses need to account for Australian dollars, GST, settlement timing, card surcharges, refunds and local payment methods, while preserving links between online orders and retail transactions in systems such as NCR Counterpoint.

Map every payment flow before migration

Start by listing every way a customer can pay and every account that receives money. The list may include Visa and Mastercard, PayPal, Apple Pay, Google Pay, buy now, pay later services such as Afterpay, gift cards, bank transfers and in-store EFTPOS. A retailer operating in Sydney may use a different mix from a regional Queensland business, but each channel needs its own reconciliation treatment.

Record the gateway account, merchant ID, settlement currency, payout schedule, fee structure and refund process for each provider. Also identify whether a transaction is authorised in the gateway, captured by the ecommerce platform or settled directly into the bank. These events are often separated by several days, so a bank deposit cannot always be matched to the order date.

Create a transaction crosswalk containing the legacy order number, new order number, gateway transaction ID, customer payment reference and settlement batch number. Preserve the old identifier in a custom field or migration note. This prevents a Magento or WooCommerce order from becoming an isolated record with no clear connection to its NCR history.

Inventory and payment records can diverge during a platform change. Reviewing an inventory differences guide helps teams separate stock discrepancies from payment discrepancies, since a missing item, cancelled order or partial fulfilment may affect the financial matching process.

Establish a cutover reconciliation window

Choose a firm cutover date and divide transactions into three groups: completed before the date, created before but settled after it, and created after the new platform went live. This prevents the common mistake of assuming that all post-migration bank deposits belong to new orders.

Run a final export from NCR Retail Online before access or data feeds are withdrawn. Include orders, payment statuses, gateway IDs, tax amounts, discounts, shipping, refunds, chargebacks and cancellations. Export gateway reports and bank statements for the same period. Save these files in an immutable location with the export date and reporting timezone.

Australian merchants should pay close attention to Australian Eastern, Central or Western time, particularly when gateway reports use UTC. An order placed late in the evening in Melbourne may appear on a different calendar day in a gateway report. Reconciliation rules should rely on transaction IDs and settlement batches first, with date and amount used as supporting evidence.

Keep the legacy gateway open for refunds and disputes for as long as its provider permits. Customers may return goods weeks after purchase, and a refund processed through the new platform may fail if the original authorisation belongs to the old merchant account. A written policy should state which system handles each refund based on the original transaction.

Build a settlement-based matching process

Reconcile in stages rather than matching the bank deposit directly to the gross order value. First compare orders with gateway captures. Next compare captures with gateway settlement batches. Then match each settlement batch to the bank deposit after deducting fees, refunds, chargebacks, reserves and currency adjustments.

A simple reconciliation record can contain gross sales, GST, shipping, discounts, gateway fees, refunds, chargebacks, net settlement and the bank statement reference. This structure makes a $9.90 fee or a small rounding difference visible instead of allowing it to disappear inside a large clearing account.

Settlement delays vary by provider and account history. A Saturday sale through an Australian gateway may settle on the next business day, while a PayPal balance may be transferred under a separate schedule. Public holidays such as Australia Day, Anzac Day and the Christmas-New Year period can extend the gap. Set matching rules around settlement batches rather than calendar-day totals.

Use a temporary payment clearing account in the accounting system. Post gross customer receipts to the clearing account when captured, record gateway costs separately, and transfer the net amount when the bank deposit arrives. The clearing account should return to zero, or to a documented balance for unsettled transactions, after every reconciliation cycle.

Preserve GST and refund accuracy

Payment reconciliation is also a tax-control exercise. GST should be calculated from the sale and adjusted correctly for credit notes, returned goods, discounts and shipping. The gateway’s net payout is not the taxable sales figure because it has already had fees or other deductions removed.

Check whether product prices are GST-inclusive and whether the new platform uses the same tax settings as the former store. This matters for Australian retailers selling across states and territories, especially when shipping charges, mixed taxable products or gift cards are involved. A small configuration error can affect Business Activity Statement reporting across thousands of orders.

Refunds deserve a separate report. Match the refund to the original order, original gateway transaction and related tax treatment. Partial refunds should show which line, freight charge or discount was adjusted. If a refund is issued from a new gateway for an old order, retain a note explaining the cross-platform relationship and reconcile the outgoing payment against the appropriate clearing account.

Run an exception report for negative settlements, duplicate captures, unmatched refunds and orders marked paid without a successful capture. These exceptions should be resolved before monthly close. Retain source gateway reports and bank statements according to the business’s accounting and audit requirements.

Control access and protect payment data

Migration work often expands access to ecommerce, gateway and accounting systems. Limit permissions according to job duties: customer service may need refund visibility, finance may need settlement reports, and developers may need integration access without the ability to issue payments. A permissions model can be rebuilt with the help of role-based access guidance, then tested against actual staff responsibilities.

Never store full card numbers or security codes in exported spreadsheets. Use gateway tokens and transaction references, and restrict reports containing customer names, addresses or partial card details. Enable multifactor authentication, separate administrator accounts from everyday accounts and review API keys after the old integration is disabled.

For Australian operations, payment security should align with the provider’s PCI DSS responsibilities and the retailer’s own handling of customer information under the Privacy Act. Staff in Brisbane, Perth or Adelaide may all access the same cloud systems, so local office controls are not enough. Centralised logs should show who changed a payment status, issued a refund or downloaded a settlement report.

Test the new gateway in a sandbox and then perform a controlled live transaction. Verify the authorisation, capture, order status, invoice, GST amount, settlement record and refund path. Use a low-value test purchase and refund it rather than relying solely on a successful checkout screen.

Monitor the new platform after launch

The first four to six weeks after migration should include daily reconciliation. Compare order totals, captured payments, refunds and gateway fees each morning, then investigate exceptions before they accumulate. Once the process is stable, move to a frequency suited to sales volume, such as three times a week or after every settlement.

Track operational measures including unmatched transactions, average time to clear exceptions, duplicate payment attempts, failed refunds and gateway downtime. A sudden rise in failures may indicate an API, webhook or currency configuration issue rather than a banking problem. Check that webhook events are idempotent so a repeated notification cannot create a second payment record.

Review the commercial settings of the replacement platform as well. Magento and WooCommerce may support different extensions, recurring billing tools and gateway connectors, so subscription costs and transaction fees should be modelled before finalising the setup. A useful subscription comparison can help distinguish software charges from payment-processing costs.

For stores serving customers in Melbourne, Sydney and other major markets, consider whether the online gateway and Counterpoint retail system record tenders consistently. Daily store takings, online settlements and marketplace receipts should be mapped to separate payment methods, even when they arrive in the same bank account. This makes cash-up procedures and management reporting much clearer.

A dependable process leaves an audit trail from customer order to gateway event, settlement batch and bank statement. Before closing each period, confirm that legacy transactions are still traceable, new transactions reconcile by gateway, fees are posted separately, and every unresolved item has an owner and explanation. The practical rule is simple: preserve the identifiers, reconcile by settlement batch, and never treat a net bank deposit as the original sale.