Start with the merchant’s next task
A merchant should not need to understand your platform’s payment architecture to choose the right menu item. Start with the tasks they need to complete and the services confirmed for their connected account. NeroConnect serves software and POS platforms and their connected merchants; partners can configure supported merchant-facing visibility settings. Confirm which settings apply before designing around them.
Create a simple service map before changing the navigation. For each proposed item, record who it is for, whether the service is available, what the destination lets the merchant do and who answers questions. Include ownership, onboarding, payment references, events and reconciliation in the wider integration review. A clearer label cannot resolve uncertainty about who owns the underlying task.
- List the merchant tasks your proposed menu needs to support.
- Confirm service availability and supported visibility options with the team.
- Assign an owner to each destination and its customer-facing explanation.
Choose between hiding an item and explaining it
Hiding an irrelevant item can reduce distraction. It is often the clearer choice when a merchant cannot use a service and has no useful action to take. However, unexplained disappearance can also cause confusion, particularly if the merchant has seen that item in earlier guidance or training. Update those communications alongside the menu.
Where your own interface supports an explanatory state, keeping an item visible may help a merchant understand an outstanding onboarding step. The trade-off is extra clutter and the risk that a visible label looks like a promise of availability. Say what is known, what needs checking and who to contact. Do not describe a service as ready merely because its menu item is visible.
A hypothetical before-and-after menu
Hypothetical example: a software partner gives every connected merchant the same Payments menu. It contains a route to an available payment task and another service whose availability has not been confirmed. The heading says, “Your payment services are ready.” A merchant selects the second item, reaches an unhelpful destination and contacts support asking why a supposedly ready service will not work.
After review, the partner uses supported visibility settings to hide the unconfirmed service. The available task keeps a clear, task-based label. In the partner’s own help area, the message becomes: “Your menu shows the payment tasks currently available to your business. If you expected another service, contact our support team so we can check its availability and any remaining onboarding steps.” This explains the change without claiming that hidden services are enabled or available on request.
The improvement is not simply a shorter menu. The merchant can identify a usable task, reach the intended destination and find an appropriate route for questions. The support team also has a specific issue to investigate rather than a vague report that payments are broken.
Keep visibility separate from access checks
A hidden menu item is not an authorisation boundary. Someone might retain an old bookmark or follow a link from previous guidance. The destination and any attempted action still need the appropriate access checks, regardless of how the person arrived there. Do not treat a successful visibility change as evidence that access controls are correct.
Review those behaviours separately with your technical owner. Test whether the navigation matches the intended merchant experience, then check how direct navigation and attempted actions are handled. Any refusal message should explain the next useful step without suggesting a workaround. If access behaviour is unclear, resolve it before presenting the menu change as complete.
- Check the menu for representative merchant account situations.
- Test retained links separately from normal menu navigation.
- Confirm that visibility changes have not been mistaken for permission changes.
Check understanding before a wider release
Ask a colleague unfamiliar with the change to follow a realistic merchant task. An observable success check is that they can identify the available service, reach the correct destination and explain what to do about a missing service without assuming it is already enabled. Check the wording in help content and support replies too; contradictory instructions can undo a clear menu.
Your next action is to review one confusing menu branch rather than redesign everything at once. Record its current labels, confirmed service position, proposed visibility and customer explanation. Agree the supported configuration with the team, test the result and give support colleagues the same explanation merchants will receive.
GOOD TO KNOW
Common questions
Does hiding a service stop a merchant accessing it?
No. Visibility controls presentation, not authorisation. The destination and attempted action still need appropriate access checks, including when someone uses a retained link.
Should every unavailable service be hidden?
Not necessarily. Hiding can remove distraction, while an explanation can clarify an outstanding step. Choose according to the merchant’s task and the supported options, without implying availability.
What should support ask when a merchant reports a missing item?
Ask which task they expected to complete, which account they were using and where they saw the service mentioned. Check confirmed availability and onboarding before promising a menu change.