Agree account ownership and onboarding responsibilities
Start by drawing the relationship between your POS platform and each connected merchant account. Record who is responsible for initiating onboarding, supplying business information and responding to questions. Confirm with NeroPay which responsibilities sit with your platform, the merchant and NeroPay; do not assume that a platform account gives your team unrestricted access to merchant information.
Consider what happens when a merchant has more than one trading location or uses more than one POS installation. Your internal records need to make it clear which business and account a payment relates to. Ask NeroPay how the supported account structure fits your intended setup before you commit to an onboarding design.
- Name an operational owner and a technical owner for the integration.
- List the merchant details and account relationships you expect to manage.
- Ask NeroPay to confirm onboarding responsibilities and access requirements.
- Document who handles an incomplete application or a change in merchant details.
Confirm environments and document the payment journey
Review the available integration documentation with NeroPay and confirm which environments are supported for your proposed use. Establish how access is requested, who can use each environment and what needs to happen before moving towards live use. Avoid designing around a presumed test environment, endpoint or device until its availability has been confirmed.
Map the journey from a POS sale to a recorded payment outcome. Identify the documented tasks your team must complete, the information needed at each stage and the points where a staff member may need to intervene. Include an unresolved or interrupted payment in the discussion, not just a straightforward successful sale.
- Ask for the relevant documentation and confirm it applies to your use case.
- List the environments, devices and access arrangements NeroPay confirms.
- Assign an owner to each documented integration task and open question.
- Agree what evidence will be needed before a live launch is considered.
Design references and event handling for reconciliation
Decide how your POS will keep its sale reference alongside the payment information available through the documented integration. Agree which reference your support team and the merchant should use when investigating a query. Confirm the format, availability and meaning of payment references with NeroPay rather than assuming that every system uses the same identifier.
Review which payment events are documented, what each one means and how your application should respond. A received event and a reconciled sale are different things: your team still needs a process for comparing records and investigating differences. Ask how to recognise an unresolved outcome and what information to retain for an escalation, without assuming that records synchronise automatically.
- Map the POS sale reference to the payment reference documented by NeroPay.
- List the supported events and the action your system or team will take for each.
- Define how staff will identify missing, unmatched or unclear records.
- Agree an escalation contact and the information to include in a query.
Review merchant visibility using a worked example
Hypothetical example: a POS provider serves a UK café with two tills. The provider wants a manager to trace a sale from either till to the appropriate payment record. Before launch, the team records which merchant account belongs to the café, how each till identifies a sale and which payment reference is available. They discuss the documented event and reconciliation process with NeroPay, including what to do if a sale cannot be matched.
The provider also asks which merchant-facing visibility settings are supported and who can configure them. The trade-off is practical: staff need enough information to investigate a payment, while access should reflect agreed responsibilities. Confirm the available settings and permissions with NeroPay rather than promising a particular screen or access level to the café.
- Use a representative merchant scenario to walk through onboarding and a sale.
- Check that an authorised reviewer can follow the agreed references between records.
- Record any visibility or permission questions for NeroPay.
- Keep a list of decisions, owners and issues to resolve before launch.
GOOD TO KNOW
Common questions
What should we bring to the first NeroPay discussion?
Bring a short description of your POS platform, the merchant account relationships you expect, your proposed payment journey and a list of questions about environments, documentation, access and onboarding. Identify the people who can make technical and operational decisions.
Can our platform choose what merchants see?
Partners can configure supported merchant-facing visibility settings. Ask NeroPay which settings are available for your use case and what permissions apply before designing or promising a particular merchant experience.
How do we know our reconciliation plan is working?
Use an agreed example to check whether an authorised reviewer can trace a POS sale to the corresponding payment record and identify any unmatched or unclear outcome. Review the result with NeroPay against the documented integration behaviour; the check does not replace your ongoing reconciliation process.
Should we assume events update every record automatically?
No. Review the documented events and their meanings with NeroPay, then decide how your application and team will handle them. Plan a separate process for checking records and investigating differences.