Design merchant sign-up
Guide a business through enrollment without confusing a saved draft, a submitted application, and approval to process payments.
Make the handoff understandable
NMI’s toolkit presents merchant onboarding as a branded platform experience supported by its merchant sign-up integration. The following screens and acceptance criteria are original Betterpay design recommendations; the required application fields and approvals must come from your actual program. onboarding
Break the journey into reviewable steps
Build the interface around the business task. Confirm the actual required data and collection mechanism before implementing any field; the categories below are an illustrative information architecture, not an API schema. Illustrative stage What the merchant should understand Design recommendation Business Which business is applying Use recognizable business identifiers and explain why required information is needed. Owners and representatives Who is authorized to complete the application Provide clear responsibility and privacy context before sensitive collection. Review What will be submitted Show a readable summary with direct edit actions. Submission result Whether the application was received Display a reference and explain the next step without promising approval.
Separate progress from eligibility
Use statuses that describe only the event you can verify. These labels are product examples, not gateway status values. Example label Meaning in your application Avoid implying Draft Information has been entered or saved by your implemented draft workflow. The merchant is approved or its application was submitted. Ready to review The interface has enough information for review. Underwriting is complete. Submitted A confirmed submission response was received. Payments may now be processed. Action needed The application needs a specific next action. A generic failure without recovery instructions. Approved and configured Approval and relevant processing configuration are confirmed. Every payment feature is automatically available.
Design recovery around the application reference
Recommended implementation sequence: Identify the merchant and authorized user before exposing application data. Explain what will be collected and where the user can find help. Validate each stage and retain only data your approved workflow is designed to store. Show a review screen and the required acknowledgments before final submission. On submission, record the actual returned application reference and outcome. Resume from the confirmed application state after a refresh or interruption.
Validate the experience with real account boundaries
A static form cannot establish merchant approval or feature activation. Test with authorized non-production accounts and program-approved test data. Confirm one merchant cannot view or resume another merchant’s application. Verify that a duplicate click does not produce duplicate applications. Handle session expiry without displaying another user’s data or silently discarding progress. Make server validation errors actionable while avoiding unnecessary sensitive details. Check that the mobile review screen exposes every submitted value and acknowledgment. Merchant onboarding requirements Prepare your launch