native by default
Native by default means that every new customer of a software platform starts on the platform's own built-in payments as the standard path, and an outside provider is set up only if the customer asks for one. It is the first of the four levers for moving existing customers.
The cheapest customer to move is one who never started anywhere else. Native by default makes the platform's own payments the path of least resistance at sign-up: the onboarding flow collects what the regulated acquiring partner needs, the customer is taking payments by the time they finish setup, and connecting a separate provider is a choice they would have to make on purpose. The option stays; the default changes.
Why it matters: a platform that lets new customers pick from a list of integrations will find most of them picking what they already know, and its payment volume grows on someone else's rails every month. Changing the default costs nothing in features and turns every new customer into payments revenue from day one. It also sets the share of customers that has moved on a rising path before any migration work starts, which is why it is the first lever rather than the last.
What to watch: the default has to be good. If built-in payments onboards slowly, pays out late or lacks a feature the trade needs, defaulting customers into it creates support tickets and a reason to distrust the later move. Build the payment products that make it the better choice, then make it the default. Nobody is prevented from choosing otherwise.
