How to Test Payment Processing Integration with Counterpoint

Payment processing sits at the point where a customer, the shop floor, the ecommerce site and the accounting system all need to agree. A sale can look successful in the browser while failing to reach Counterpoint, creating a stock discrepancy, a missing receipt or an unsettled refund. Testing the connection properly means checking the entire transaction path, not simply entering a card number and looking for an approval message.

For Australian retailers, the setup may include Counterpoint POS, an online storefront, an EFTPOS terminal, a payment gateway and a merchant settlement account. The process must handle Australian dollars, GST, card surcharges, refunds and local payment methods without creating duplicate records. A test that works in a Sydney showroom may still expose problems when a Perth customer places an order across a different operating schedule.

The work is especially important for businesses moving away from NCR Retail Online. NCR announced that the product was discontinued, requiring customers to transition to alternatives such as Magento and WooCommerce through NCR Counterpoint partners. During that transition, payment integration testing helps confirm that the new ecommerce layer still communicates correctly with Counterpoint and the selected processor.

A reliable test plan covers successful payments, declined cards, interrupted checkouts, cancellations, refunds, chargebacks and stock updates. It also checks security controls, reconciliation reports and staff workflows. The aim is to prove that every payment outcome produces the correct business result in the right system.

Map The Full Transaction Path

Start by documenting what should happen from checkout to settlement. A typical flow sends cart details from the online store to the payment gateway, receives an authorisation response, creates or updates an order, reduces available inventory and posts the sale to Counterpoint. Depending on the configuration, capture may happen immediately or after fulfilment.

Record each system involved, including the storefront, integration middleware, Counterpoint database, payment provider, tax configuration and reporting tools. Note whether orders are imported in real time or in batches. A delay of several minutes may be acceptable for a small retailer, while a busy Melbourne store selling limited-release products may need near-real-time updates.

Use test credentials and a sandbox environment wherever the processor provides one. Keep test products, customers and tender types separate from live records. If the integration cannot fully simulate settlement, use a tightly controlled live transaction for the final check and refund it promptly, with approval from the finance manager.

Configure Australian Payment Rules

Confirm that the gateway is configured for AUD and that amounts are transmitted in cents according to the provider’s API rules. Check the GST treatment for taxable products, freight and discounts. The order total shown in Counterpoint should match the amount authorised by the gateway, including any permitted surcharge or delivery charge.

Australian retailers may accept Visa, Mastercard, American Express, EFTPOS, mobile wallets and buy-now-pay-later services such as Afterpay. Each method can produce different response codes, settlement timing and refund behaviour. Test every payment type that the store advertises rather than assuming that a successful Visa transaction proves the whole configuration works.

Pay attention to Australian Consumer Law obligations. A refund triggered in the ecommerce platform should be visible to staff in the same way as an in-store refund, with a clear audit trail. If a customer rings from Brisbane about a failed refund, the service team should be able to locate the original order, payment reference and refund status without searching across disconnected systems.

Run Successful Payment Scenarios

Create a test order using a low-value product with a known stock quantity. Complete checkout with a sandbox card and verify the approval message, order number, payment status and receipt. Then check that Counterpoint records the order against the correct customer, location, sales representative and tender type.

Compare the transaction amount in all relevant records. The gateway, ecommerce platform, Counterpoint receipt, tax report and settlement export should agree, allowing for any documented rounding rules. Confirm that inventory decreases once, rather than staying unchanged or being reduced twice by separate synchronisation jobs.

Repeat the test with freight, a discount code, multiple quantities and a mixed tax situation if the business sells products with different GST treatment. A retailer in Adelaide may have a different delivery charge from a customer in regional South Australia, so test postcode-based shipping rules as well as metro orders.

Test Declines And Interrupted Checkouts

Use the processor’s test cards or response codes to simulate insufficient funds, expired cards, suspected fraud and gateway timeouts. The storefront should display useful language without exposing technical details. The order should remain unpaid or move into a clearly defined pending state, and Counterpoint should not treat it as a completed sale.

Close the browser after authorisation but before the confirmation page loads. Also test a customer pressing the payment button twice, losing mobile coverage and returning to an abandoned checkout. These cases help identify duplicate orders, duplicate authorisations and confusing customer emails.

Check what happens when the gateway approves a payment but the order import fails. The integration should either retry safely or flag the transaction for review. A queue, webhook log or exception report is valuable here because staff in a busy Queensland shop cannot manually inspect every order during the afternoon rush.

Verify Refunds, Voids And Reconciliation

Test a full refund, a partial refund and a refund against an order containing several products. Confirm that the gateway sends the money back to the original payment method and that Counterpoint records the correct quantity, tax amount and reason. If a refund is started in Counterpoint, verify whether it reaches the processor automatically or requires a separate staff action.

Test a void before settlement and a refund after settlement, since these are often different gateway operations. Check the customer email, internal notes and audit history for each result. The transaction should remain traceable through a consistent order ID, payment ID or reference number.

Reconcile the day’s test transactions against a gateway report and a Counterpoint tender report. Include approved payments, declined attempts, refunds, fees and any pending items. Australian settlement files may arrive according to the provider’s business day rather than the store’s local calendar, so confirm how public holidays and weekend trading affect reporting.

Check Security And Operational Controls

Never place real card numbers, CVV values or full payment details in Counterpoint notes, ecommerce logs or support tickets. Confirm that the gateway uses tokenisation and that staff receive only the payment information needed for their role. Review administrator access, API keys, webhook signatures and password policies before enabling the production connection.

Inspect logs for sensitive data and verify that failed requests do not reveal credentials. Test an invalid webhook signature and confirm that the platform rejects it. Review PCI DSS responsibilities with the payment provider and integration partner, especially if any part of the checkout is hosted on the retailer’s own infrastructure.

Test operational controls from a staff perspective. A team member should know how to identify a payment that is pending, duplicated or reversed, and when to escalate it. If stock alerts and customer messages are part of the process, review back-in-stock notifications after a cancelled or refunded order so that inventory changes do not trigger inaccurate promises.

Validate Inventory And Go-Live Monitoring

Payment testing is incomplete until inventory behaviour is verified. Place an order for the last available unit, then check the online quantity, Counterpoint quantity and any location-level inventory record. Cancel or refund the order and confirm the intended stock adjustment without creating an extra unit or reopening an item that is still reserved.

Run competing tests with an online order and a Counterpoint sale close together. This is important for retailers with a shop in Sydney, a warehouse in Newcastle and online customers ordering at the same time. The system should have a defined rule for reservations, overselling and failed synchronisation rather than relying on staff to repair records later.

During migration, redundant inventory checks can reveal issues that payment-only testing misses. The guidance on inventory checks during migration is particularly relevant when a new Magento or WooCommerce store is connected to existing Counterpoint data.

Before launch, create a sign-off sheet covering payment approval, decline, timeout, duplicate-click, void, refund, settlement, stock and security tests. Assign each result to a named staff member and retain screenshots or transaction references. For the final production check, process one approved AUD transaction, verify it in Counterpoint and the gateway report, then complete the documented refund.