Guide
Merchant onboarding
Onboarding is not a signup animation—it is access control, environment configuration, and integration alignment for moving value.
Definitions: Merchant approval · Selected rails · Withdrawal request
Conceptual operational diagram for this guide. Not live merchant data or metrics.
01
What is merchant onboarding here?
It is the path from first contact to an approved merchant environment where rails are enabled intentionally and integration materials match what you will run in production.
02
Why does onboarding matter operationally?
Because enabling payments without aligning on risk, rails, and operational controls creates predictable incidents: wrong network assumptions, reconciliation surprises, and fragile webhook consumers.
03
How does onboarding typically proceed?
Teams exchange context (business fit, rails, volumes), complete approval and environment setup, then integrate server-to-server and verify webhooks with idempotent handlers.
Public marketing pages cannot promise timelines; your intake thread is the right place for scheduling and next steps.
04
Common mistakes
- Treating approval as “broken UX” rather than intentional gating.
- Assuming test hosts or signing details are globally public before you receive materials.
- Skipping reconciliation design until after launch traffic arrives.
05
Security considerations
Never send private keys, seed phrases, or webhook secrets in email. Legitimate onboarding never requires you to expose custody secrets to a vendor.
Read: Contact — request access (what to include, what never to send), Server-side API keys.