The Three GTM Playbooks in Cross-Border Payments
FX & Float Memo #4
There are only three ways to acquire customers in cross-border payments. Every payments company uses one as its primary engine, incorporates elements from the other two, and the outcome is its “GTM strategy.”
But the playbooks for these three approaches are not interchangeable. Each one requires a different team, a different cost structure, a different product architecture, and has a different timeline to profitability. Picking the wrong playbook, or trying to run all three at once, is one of the most common and most expensive mistakes a payments company can make.
What most companies believe
Conventional wisdom tells us that GTM in payments is a sales problem. So you build the product, hire a sales team, and start calling prospects. If the product is good, customers will come. If growth is slow, hire more salespeople. If a particular channel works, double down on it.
This way of thinking treats distribution as something built separately and then attached to the product. This is wrong. In payments, the distribution model shapes the product itself. A product built for marketplace partnerships looks fundamentally different from one built for enterprise sales, and neither of them looks like a self-serve product. The GTM decision is a product decision, and making it late or making it wrong wastes years of effort.
Playbook 1: Platform and marketplace partnerships
This is the model that Payoneer has pioneered. Instead of acquiring individual business customers one by one, the payments company partners with a platform that already has thousands of them. Freelance marketplaces, e-commerce marketplaces, and gig economy platforms. The platform integrates the payments company into its payout flow, and the payments company acquires the platform’s customers at scale.
The economics look very attractive. Customer acquisition cost is close to zero for any incremental customer because the platform delivers them in bulk. A single partnership with a major marketplace can bring 50,000 customers overnight. The marketplace does the distribution for the payments company.
But five things make this playbook harder than it appears-
First, the sales cycle is long, and the conversion rate is low. Signing a platform partnership in payments is a lengthy cycle involving legal review, compliance alignment, API integration, commercial negotiations over revenue share, and often a pilot period. A partnership that starts as a conversation at a conference in January might go live in December.
Second, the customer you acquire through a platform is their customer, not yours. They use you because the marketplace told them to. Their loyalty is to the platform, not to you. If the platform switches providers, the customers leave with it. This means the retention forces described in Memo #2 (integration depth, settlement dependency) operate at the platform level, and not the individual customer level. Losing one marketplace relationship can mean losing thousands of customers at one go.
Third, the margins are thinner by design. The platform expects a revenue share or a preferential rate in exchange for delivering its volume. In a well-negotiated platform deal, the payments company might retain 60-80% of the gross revenue per transaction. In a poorly negotiated one, it could be only 20-30%. This means high volume, but low margin per transaction. This playbook only works at scale. At anything less, it can be painful.
Fourth, you have no control over your customer economics. If your unit economics on a particular corridor or customer segment are not working, you cannot fix it. You cannot decide not to onboard some customers. You cannot reprice the customer directly. You cannot change the onboarding flow to push them toward higher-margin products. Everything flows through the platform, and the platform’s priorities are not the same as yours.
Fifth, the marketplace has an obvious incentive to work with multiple payment providers. Working with a single payout partner makes the marketplace operationally fragile. If that partner’s service is disrupted due to a compliance issue, a banking partner outage, or any other reason, the platform’s payouts stop. So the platform wants to sign a second and a third provider. Now you are competing on price and reliability with other providers in the same account. The relationship that was like a partnership when you signed the deal starts to resemble a competition. And you are at a disadvantage because the marketplace has optionality, while you have a dependency.
The companies that succeed with this playbook share a common trait: they build the product around the platform’s needs, not the end customer’s. The onboarding flow, compliance documentation, payout options, and reporting dashboard - all of it is designed to reduce friction for the platform, because the platform is the real buyer. The end customer’s experience matters only insofar as it reduces the number of support tickets that flow back to the platform.
Playbook 2: Direct self-serve
This is what Wise has mastered. In this playbook, the customer discovers the product (through word of mouth, search, or advertising), signs up, completes onboarding, and sends a payment. The entire journey is zero-touch self-serve.
The economics of this playbook are different. Customer acquisition cost is higher per customer because each one is acquired individually through marketing spend. But the margin per customer is also higher because there is no marketplace taking a revenue share. And the customer belongs to the payments company, not to a marketplace.
The product requirements for this playbook are quite high. The onboarding has to be fast and frictionless, which means the compliance process needs to be largely automated. Pricing has to be transparent because a self-serve customer has no one to explain the fee structure. The product has to be intuitive enough that a first-time user can complete a transaction without help, which means the complexity of cross-border payments (multi-currency, compliance documentation, variable delivery times) has to be absorbed entirely by the interface.
(This is one reason Wise made the FX markup visible. Transparency is a product requirement of the self-serve model. A customer who has no one to call needs to trust the price on the screen.)
This makes the self-serve playbook expensive to build. Building a product that requires zero touch means investing more in design, automation, and compliance technology upfront. The payoff is that at scale you have a much lower marginal cost per customer. But the upfront investment is significant, and the time to reach scale can be long.
The self-serve playbook also has a natural ceiling in B2B payments. While a freelancer sending $500 can self-serve easily, a mid-market company with $250,000 across four corridors typically cannot. The customer’s internal processes (procurement, legal, treasury) need a human conversation to navigate. This is where many self-serve payments companies hit a wall - they saturate the small-business segment and struggle to move upmarket without adding a sales layer.
Playbook 3: Enterprise sales-led
This is the Adyen model, and also increasingly the Stripe model. Here, a sales team identifies target accounts, runs a consultative sales process with custom pricing, manages the technical integration, and maintains the relationship through dedicated account management.
Here, the economics are inverted compared to the self-serve model. Customer acquisition cost per account is very high. A single enterprise deal can take 6 to 12 months to close and involve solutions engineers, legal teams, and multiple stakeholders. But the revenue per account is also very high. One enterprise client doing $50 million in annual cross-border volume generates more revenue than 10,000 self-serve customers sending $500 each.
This playbook requires a fundamentally different product. Enterprise customers need custom pricing (as covered in Memo #1, the gap between the stated fee and the negotiated rate is widest in enterprise). They need bespoke integration with their existing ERP and treasury systems. They need SLAs on settlement timing, uptime, and support response. They need dedicated compliance handling for their specific industries. All this means the product cannot be standardised the way a self-serve product can be. It has to be configurable, and configuration requires human touch.
The risk of this playbook is the pricing death spiral described in Memo #3. Enterprise customers are acquired at custom rates that assume volume growth. When the growth does not materialise, the rate becomes the permanent rate. When the company tries to adjust, the customer threatens to leave. The discounting cycle begins. This spiral is common in enterprise sales because each deal is a unique negotiation, but ends up setting a precedent.
The other risk is concentration. A payments company with 30% of revenue coming from three enterprise clients is sitting on huge concentration risk. If any one of these clients renegotiates its price or churns, the revenue impact is immediate and significant.
The companies that succeed with this playbook share three characteristics -
First, they treat pricing as a system, and not a series of negotiations. They build structured pricing tiers with clear rules for custom rates, and they have the discipline to walk away from deals where the margin does not work. As covered in Memo #3, this discipline is hard to implement. Adyen is known for not chasing price-sensitive merchants. They are rarely the cheapest option in a competitive process, and they do not discount aggressively to win. This means they lose some deals. But the deals they win are at healthy margins with customers who value reliability over cost.
Second, they go deep in specific verticals rather than selling horizontally to anyone who takes their meeting. Adyen built vertical expertise in travel, retail, marketplace platforms, and digital goods. Their sales team understands chargeback patterns in travel, the omnichannel requirements of retail, and marketplace payout complexity. This leads to a sales conversation that a generalist competitor cannot have, and it builds a product that gets better for each vertical over time.
Third, they focus their account management teams on technical after-sales rather than on relationships. They anchor the conversation on optimising authorisation rates, reducing declines, and improving checkout conversion. These are product conversations, not pricing conversations. When the value delivered is tangible, the cost of switching becomes high.
Most companies try three and fail at two
Most payments companies, especially ones between Series A and Series C, try to run two or three of these playbooks simultaneously. They have a partnerships team chasing platform deals, a marketing team running self-serve acquisition, and a sales team closing enterprise accounts.
This rarely works. Each playbook requires a product built around it. The self-serve product needs zero-touch onboarding and transparent pricing. The enterprise product needs configurability and custom pricing. The platform product needs to be built around the platform’s API and operational requirements. Building a single product that serves all three is technically possible, but extremely difficult. It almost always results in a product that serves none of them well.
But the constraint is beyond just product. Operations, compliance and licensing - all have to be designed around the chosen playbook. A self-serve model requires automated KYC and compliance flows that can support thousands of applications without human review. An enterprise model requires customised compliance handling, with dedicated teams that can navigate a client’s specific regulatory requirements across jurisdictions. A platform model requires compliance frameworks that work at the platform level, not the individual customer level, which is a fundamentally different architecture.
The same applies to the entire operations - settlement cycles, customer support, escalation workflows, and treasury management. Each looks different depending on whether you are serving 100,000 self-serve customers, 500 enterprise accounts, or 5 platform partnerships. A support team built for high-volume, low-touch self-serve queries cannot handle the complex, multi-stakeholder escalations that enterprise clients expect. A treasury team optimised for pre-funding a handful of corridors for platform payouts cannot manage the corridor diversity that a self-serve model with global customers demands.
When a company tries to run all three playbooks, it is not just the product that gets stretched. It stretches the entire operating model. It could end up with compliance processes that are too manual for self-serve and too generic for enterprise, or operations SLAs that are too slow for platforms and too expensive for small customers, or licensing decisions that are made to support one playbook, but which create constraints for another.
This also creates an organisational problem. The partnerships team, the sales team, and the marketing team each have different incentive structures and different definitions of success. Their incentives and definitions of success can, and invariably will, conflict. A self-serve customer acquired through marketing at a $50 CAC with transparent pricing does not want to learn that an enterprise customer with the same volume pays half the rate because they negotiated.
What this means
The GTM decision in payments is not a simple go-to-market decision. It is a strategic decision that has bearing on the product, the org structure, the pricing model, and the unit economics.
This means three things for payments companies -
First, the playbook you choose constrains your entire organisation, not just your product. A self-serve product cannot be retrofitted for enterprise without significant investment in engineering, compliance, operations, and customer support. An enterprise operation cannot be simplified into a self-serve experience by removing features and people. These are not just adjustments - they need rebuilding across every function.
Second, the unit economics of each playbook are fundamentally different. Comparing payments companies across playbooks using the same metrics is misleading. A platform-partnership company with $10 billion in volume and thin margins is not comparable to a self-serve company with $1 billion in volume and high margins. They are both playing different games with different scorecards.
Third, “we’ll do all three” is not a strategy. It is an indirect admission that the company has not yet made the GTM decision. And the longer this decision is deferred, the more expensive it becomes. The product, compliance, operations, organisation structure, and pricing structure continue to accumulate debt as they serve multiple models simultaneously.
Every payments company has a GTM strategy. Yet, most of them end up running three. And that is the problem.
