Glossary · Updated 19 October 2026

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.

Start with a payments review.

Thirty minutes on your platform, your product and how your customers pay today. We talk through what you want to build, what would make customers use it and where you need our help.