Start with what your platform can actually present
NeroConnect connects software and POS providers and their merchant accounts to payment services. Partners can configure supported merchant-facing visibility settings. That gives platform operators a starting point for product discovery, but it does not establish any particular AI Reception capability, integration or commercial arrangement. Confirm availability and the supported presentation options with the team before deciding what merchants will see.
Choose between publishing a confirmed discovery route and holding the item back until its destination is ready. Early visibility can help merchants find information, but an incomplete route creates avoidable questions. Do not describe a service as ready to use simply because its name appears in a menu. Keep the wording aligned with what the merchant can genuinely do next.
- Confirm whether AI Reception can be presented to the intended merchant accounts.
- Check which visibility settings are supported for your platform.
- Agree the destination and wording before enabling the discovery route.
Keep discovery separate from the merchant’s subscription
The discovery stage answers a narrow question: where can the merchant learn about the service and find their next step? Subscription and setup are separate stages. Direct merchants to their own confirmed workflow rather than implying that a platform operator has subscribed on their behalf. A connected payment account should not be presented as evidence that another service is already active.
This distinction should be visible in both interface copy and support replies. Use action wording that matches the destination: information should lead to information, while setup wording should lead to a verified setup route. Confirm commercial terms before describing any charge or inclusion. Do not assume that software inclusion associated with an eligible NeroPay terminal extends to AI Reception.
- Read the menu label and destination together: do they promise the same thing?
- Make clear when the merchant is leaving discovery and entering their own subscription or setup process.
- Remove any wording that suggests automatic activation or inherited access.
Map ownership across the systems involved
Write down who owns each stage before making the route visible. Your platform may own its menu wording and the supported visibility configuration; the merchant must be directed to their own subscription and setup workflow. Confirm who answers questions about availability, account access and setup progress rather than leaving merchants to move between teams without a clear destination.
NeroConnect integration planning includes ownership, onboarding, payment references, events and reconciliation. Review these areas where they genuinely touch the proposed journey. Do not infer that displaying AI Reception creates payment events, transfers merchant information or synchronises account status. If a proposed handover depends on information moving between systems, verify that behaviour explicitly before relying on it.
- Record the owner of discovery, subscription questions and setup questions.
- Identify any information the handover would require and confirm supported handling.
- Document relevant payment references and reconciliation responsibilities, or state that they are outside this discovery change.
A hypothetical merchant journey with clear boundaries
Hypothetical example: a POS platform wants its connected café merchants to discover AI Reception. Before changing its merchant menu, the operator confirms availability, the supported visibility settings and the correct destination with the team. It then prepares wording that introduces the service without claiming what it can do or suggesting that it is already included in the café’s account.
A café owner selects the item and reaches the agreed information or subscription starting point. They follow their own subscription and setup workflow; the platform does not mark them as active merely because they selected the menu item. If the owner asks why setup is unfinished, support uses the agreed ownership map to direct the question appropriately, rather than assuming a payment connection has completed the process.
Check the handover before widening visibility
An observable success check is simple: from a merchant account intended to see the item, the route reaches the agreed destination, the wording accurately describes that destination, and the merchant can identify their next action. Also check that visibility follows the confirmed configuration. A successful discovery test does not prove subscription, setup completion or service readiness.
Keep a record of the wording, destination, settings checked and unresolved questions. If any stage is unclear, resolve it with the responsible team before extending visibility. Your next action is to prepare a one-page journey map and ask the team to confirm availability, supported settings, commercial boundaries and the merchant’s subscription and setup route.
GOOD TO KNOW
Common questions
Does showing AI Reception in a menu activate it?
No. Treat menu visibility as discovery, not evidence of subscription or completed setup. Direct the merchant to their own confirmed workflow.
Can partners configure what merchants see?
Partners can configure supported merchant-facing visibility settings. Confirm which settings apply to your platform before designing the journey.
Will merchant details or status synchronise automatically?
Do not assume automatic synchronisation. Confirm any required information transfer or status behaviour with the team before building it into the workflow.
What should merchants be told about cost?
Use confirmed commercial terms only. Do not describe AI Reception as free or included based on a terminal arrangement or an existing connected account.