1. Map responsibilities before designing screens
NeroConnect serves software and POS platforms and their connected merchant accounts. Begin by listing the information required for the confirmed onboarding process. For each item, record who supplies it, where it is collected and who can confirm that the step is complete. Do not assume that information already held by your platform can be transferred or reused.
Keep information ownership separate from resolution ownership. A business owner may need to supply a missing detail, while your support team owns explaining the request and tracking the follow-up. Agree who handles questions that platform staff cannot resolve, without promising approval or completion times.
- Create a responsibility table covering the merchant, platform operations, development and the relevant NeroPay contact.
- For each step, record the supplier, resolution owner, completion evidence and escalation route.
- Confirm supported capabilities and responsibilities with the team before treating the table as a development specification.
2. Choose how merchants supply information
Decide how much guidance merchants need from your platform. A more guided experience can explain unfamiliar requests at the point they arise, but it also creates more wording and support responsibilities. A lighter experience may be simpler to maintain, provided merchants still know where to act and where to get help. Confirm the supported onboarding approach before choosing either design.
Avoid collecting information merely because it might be useful later. Map each requested detail to a confirmed onboarding need and explain its purpose plainly. Where a merchant must complete a step elsewhere, make the handover explicit: what they need to do, who handles the next decision and how they should check progress. Do not imply automatic data synchronisation.
3. Show evidence, not assumptions
Draft a small set of proposed display states, such as information needed, submitted and awaiting confirmation. These are design labels to validate, not claims about NeroConnect status names. Define the evidence required for each label. A merchant pressing submit proves an action was taken; it does not by itself prove that the account is ready for payment activity.
Partners can configure supported merchant-facing visibility settings. Agree which information is useful to show and which details belong with the responsible support team. Explain the next action without exposing unnecessary internal detail. If progress cannot be confirmed, say so rather than displaying a reassuring completion message.
- Document the confirmed source of evidence for each displayed state.
- Specify the message and responsible contact when evidence is missing or unclear.
- Check that visibility choices do not suggest broader access or bypass permissions.
4. Test a missing-information journey
Hypothetical example: a UK POS software partner is preparing onboarding for a café owner. The owner submits the requested business details, but one required detail remains incomplete. The platform must not present the submission as finished onboarding. Its proposed message identifies that further information is needed and directs the owner to the confirmed route for completing that step.
The partner’s support lead owns following up with the café owner; the owner supplies the missing information. The technical team checks that the platform displays only progress supported by confirmed evidence. Use an agreed test method with the team, rather than assuming a particular test environment or event behaviour is available.
- Walk through the initial submission and leave one agreed required detail incomplete.
- Check that the merchant sees a clear next action and support staff can identify the resolution owner.
- Complete the missing step through the confirmed process, then check when the display may change.
- Record a pass only if the screen follows the evidence and the handover leaves no ownerless task.
5. Connect onboarding to payment operations
Plan payment references, events and reconciliation alongside onboarding, not after it. Agree how your platform will associate a connected merchant account with its own business record, and which confirmed references operations staff will use to investigate payment questions. Document how supported events affect your records without assuming instant updates or automatic synchronisation.
Your next action is a joint review of the responsibility table, proposed messages and test results. Include the people who will handle merchant queries and reconciliation, not just developers. Confirm product availability, integration details and commercial terms with the NeroPay team before committing the merchant experience to a launch plan.
GOOD TO KNOW
Common questions
Who should resolve an incomplete onboarding step?
Assign a named role for each step. The merchant may supply the information, while platform support explains the action and owns follow-up. Confirm escalation responsibilities with the team.
Can our platform show onboarding as complete after submission?
Only when confirmed evidence supports that message. Submission and completion are different milestones, so define and validate the evidence needed for each displayed state.
Can partners choose what merchants see?
Partners can configure supported merchant-facing visibility settings. Confirm the available options before designing screens; visibility settings do not imply unrestricted access or permission bypasses.