1. Agree what counts as payment confirmation
An order records what a customer wants to buy. A payment result records what happened to a payment attempt. A checkout completion screen, an order number or a customer's report that they paid should not, by itself, move the order into a confirmed-paid state.
Before implementation, agree which payment record and outcome your team will use as evidence. Confirm the available status meanings with the payment service team rather than guessing from labels. Keep payment confirmation distinct from settlement or accounting reconciliation: evidence that an attempt succeeded is not necessarily evidence that funds have reached the merchant's account.
- Document the evidence required to mark an order paid.
- Define separate operational states for awaiting a result, confirmed success, confirmed failure and unresolved exceptions.
- Agree whether fulfilment pauses while a result remains unclear.
2. Build a reference trail for each merchant
Start with the merchant account, platform order reference and payment-attempt reference. One order may have more than one attempt, so do not overwrite the original attempt when a customer retries. Preserve enough history to explain which result caused an order status change.
NeroConnect serves software and POS platforms and their connected merchant accounts. Integration planning includes onboarding, ownership, payment references, events and reconciliation. Confirm what information is available through the agreed implementation; do not assume automatic synchronisation. An amount and approximate time can help an investigation, but are not a dependable unique match.
- Record the merchant context alongside every order-to-payment link.
- Keep each attempt separately identifiable.
- Check references, amount and currency before accepting a match.
3. Process results without losing unresolved orders
Decide how your platform receives or reviews payment results using the supported arrangements confirmed during planning. Define what happens when a result arrives after the customer has left checkout, arrives more than once or cannot be linked confidently. These are workflow requirements to agree, not assumptions about built-in capabilities.
Maintain an exception queue with an owner, reason and next review time. A missing result should remain unresolved until checked; automatically calling it failed could encourage an unnecessary second payment. Equally, treating it as successful could release goods without confirmation. Choose a review interval that suits the merchant's fulfilment process and make the holding message clear.
- Match the result to its merchant, order and payment attempt.
- Apply the agreed status rule without repeating fulfilment for a repeated result.
- Send unmatched or conflicting records to investigation.
4. Walk through a delayed result before allowing a retry
Hypothetical example: a takeaway platform creates order T184 for £28. The customer reaches the end of checkout, but the platform has no verified payment outcome. The order remains awaiting confirmation and the merchant sees that preparation is on hold. This is an example workflow, not a description of an automatic NeroConnect feature.
An operations colleague checks the agreed payment record using the merchant and attempt references. If success is verified, they record the evidence and release the order under the merchant's rules. If failure is verified, they follow the agreed retry process. If the result remains unclear, they escalate rather than asking the customer to pay again immediately. Any retry gets its own attempt reference.
- Tell the customer: Your order is recorded, but payment confirmation is still being checked.
- Record who checked the result and when.
- If multiple successful attempts are found, follow the merchant's agreed duplicate-payment review process.
5. Close exceptions and prove the workflow works
Agree who owns each handover: the merchant handles fulfilment decisions, platform operations investigates order links, and the appropriate payment service contact helps resolve payment-record questions. Confirm responsibilities with everyone involved. Partners can configure supported merchant-facing visibility settings; check which settings are available and ensure displayed wording matches the operational state.
The observable success check is simple: every reviewed order either has a traceable payment outcome or a named exception owner with a next action. Test a successful payment, a failed attempt, a delayed result and a retry before relying on the workflow. Your next action is to take one unresolved order through these checks with your platform and payment contacts, then document any gaps.
GOOD TO KNOW
Common questions
Can an order confirmation count as payment confirmation?
Not on its own. It confirms that an order exists. Mark payment confirmed only when the agreed payment evidence supports that outcome.
What should happen if the customer says they have been charged?
Acknowledge the concern and investigate the original attempt. Do not dismiss their report or request another payment solely because your platform lacks a result.
Should every unresolved order be cancelled?
No. Agree a holding and review policy suited to fulfilment. Cancellation of an order should not be assumed to cancel or reverse a payment.
What should we confirm before implementing this with NeroConnect?
Confirm supported payment information, event handling, reference mapping, merchant visibility settings and escalation responsibilities with the team. Availability and implementation details need checking.