Navigating the global payments frontier - an interview with Fastspring's Christopher Bunk

• A merchant of record is not just a 'payments layer'.
• Potential step-change in how developers integrate, operate and scale commerce globally. 
• Studios are asking how commerce integrates into their live operations.
• "Don't underestimate the operational complexity of selling globally."

The PocketGamer.biz team sat down with Christopher Bunk, who recently joined Fastspring, the payments, subscriptions and automated tax compliance expert, to find out more about his background, his new role at the company and its plans to support the rapidly evolving global mobile games market.

Pocketgamer.biz: You recently joined FastSpring as Chief Product and Technology Officer. What was it about the company's position in the global payments and merchant of record space that made this the right move for you at this stage of your career? 

Christopher Bunk: I came into this role at an interesting moment, both personally and for the industry. I spent most of 2024 on what I would call a deliberate sabbatical. Not to decompress and not to consult, but to go fully hands-on with AI development. I believed the shift was too significant not to engage with directly.

I went deep with tools like Cursor, Windsurf, and Claude Code, built systems, and spent time with a community of senior technologists doing the same. I came out of that period with real practitioner-level fluency in enterprise-grade agentic engineering and a clear view of how fundamentally it is going to reshape how software gets built. 

I was then looking for the right place to apply that, and FastSpring stood out because of where it sits in the value chain. A merchant of record is not just a payments layer. It abstracts away a significant amount of operational and regulatory complexity for developers, including tax, compliance, fraud, and global currency management. That position in the stack matters even more in a Gen-AI world. 

As software creation accelerates and more teams, including smaller and more distributed ones, are able to build and launch globally, the complexity around monetisation, compliance, and global operations does not go away. If anything, it becomes more pronounced. That creates a structural advantage for platforms like FastSpring that already own that layer of abstraction.

We're seeing a significant move in the mobile industry toward web stores and direct-to-consumer strategies. From a technical perspective, what are the biggest hurdles a studio faces when trying to move players away from online storefronts and app stores? 

The shift toward direct-to-consumer is a natural progression, and it starts with how the industry has evolved. 

For a long time, studios and publishers relied on app stores and marketplaces to handle large parts of the user commerce experience. That made sense early on. You traded control for speed to market, and the tradeoff worked. But as games have become more service-oriented and live-ops driven, that model starts to show its limits. Studios now want more control over the player relationship, more flexibility in how they monetise, and the ability to deliver richer, more integrated experiences outside the constraints of a marketplace. 

The first set of challenges is around experience and performance. Studios are effectively trying to recreate something that feels as seamless as an in-game purchase flow, but in a much more open and less controlled environment. That means fast session initialisation, low-latency interactions, and a checkout experience that can be deeply customised without introducing instability. If the experience feels even slightly slower or more fragmented than what players are used to, conversion drops immediately, especially during high-intensity moments like live-ops events. 

The second challenge is around developer experience. Building and maintaining these systems requires stitching together multiple layers, frontend experience, backend services, identity, payments, entitlements, and live-ops systems, into something that feels cohesive. Without strong abstractions, this quickly becomes a tax on engineering teams and slows down iteration at exactly the moment when studios are trying to move faster. 

And then there is the operational layer, which is often underestimated. Once you move off-platform, you take on global tax compliance, fraud exposure, currency handling, chargebacks, and regulatory obligations. Those are not edge cases; they are core requirements, and they scale with your success. 

For developers who might be unfamiliar with the term, how would you describe the fundamental difference between a simple payment processor and a merchant of record like FastSpring? 

A payment processor handles the transaction. That's it - it moves money from a player's card to your account. Everything else is your problem: VAT in Germany, sales tax in California, regulatory compliance across 200+ jurisdictions, fraud liability, chargebacks, and currency conversion. 

A merchant of record takes on all of that on your behalf, similar to how app stores do today, but at a fraction of the cost. We become the seller of record in every transaction, which means we own the tax obligation, we own the fraud risk, and we handle compliance globally. For a small to mid-sized studio, that's not a minor operational convenience - it's the difference between having a back-office finance and compliance team or not having one. We essentially let you behave like a global publisher without building the infrastructure that role normally requires. 

What are the core principles you follow when building tools and APIs that need to be integrated into a studio's existing publishing and live-ops pipeline? 

The first principle is that developer experience is a competitive outcome, not just a design preference. In a bake-off against other platforms, our SDK and API story is often the deciding factor. Studios are making judgments before they ever talk to us, based on what they see in our documentation and how easy it is to understand and get started. That is why we are investing in componentised approaches similar to Stripe Elements, where developers get discrete building blocks they can place and style exactly how they want within the necessary compliance boundaries. 

But developer experience is not just about surface area. It is defined just as much by the non-functional characteristics of the platform. Observability, how easy it is to understand what is happening in production. Error handling, whether failures are predictable and actionable or opaque and difficult to debug. Scalability, whether the system behaves consistently under load, especially during critical moments like launches or live-ops events. These are the things developers feel day two and beyond, and they often matter more than the initial integration. 

The second principle is that extensibility should not require tradeoffs. Developers should be able to deeply customise the checkout experience without sacrificing performance or reliability. The goal is flexibility with strong guarantees, not flexibility at the cost of stability. 

That becomes even more important as the shape of user experiences continues to evolve. We are no longer in a world of fixed, cookie-cutter checkout flows. Studios are experimenting with new interaction models, tighter integration with gameplay and live-ops, and more dynamic commerce experiences. The platform has to support that evolution. 

The third is that developer experience drives long-term retention. A developer who has a clean integration experience, with clear documentation, strong operational visibility, and predictable APIs, is far more likely to stay and expand their usage over time. That is not just an onboarding concern; it is a core part of the long-term relationship. 

Ultimately, this is about treating developers as partners. The platform’s role is to expand what is possible for them, while providing the reliability and clarity they need to move quickly and confidently in a rapidly changing environment. 

In a world of agentic AI and automated workflows, how do you ensure your product maintains a level of reliability that a studio can trust with its entire revenue stream? 

I would push back on the idea that automation and reliability are in tension. The real distinction is not automation versus human oversight; it is deterministic systems versus non-deterministic ones. 

In our domain, especially around payments and the broader merchant of record stack, the core user flows have to be completely deterministic and bulletproof. You cannot have variability in how a checkout behaves, how tax is calculated, or how a transaction is processed. Those systems need to be predictable, testable, and correct every time. 

Where modern development approaches, including AI-assisted development, come into play is in how you achieve that level of rigour. Historically, getting to world-class reliability required significant time and effort across areas like detailed specification, comprehensive test coverage, strong observability, and robust validation of edge cases. 

What is changing is that it is becoming much more feasible to operate at that level of discipline consistently. You can be more ambitious about the completeness of your specifications, the depth of your test coverage, and the visibility you have into system behaviour in production. 

But the output still needs to be deterministic. The goal is not to introduce non-deterministic behaviour into critical paths. It is to use better tools and practices to build systems that are more reliable, more observable, and more thoroughly validated than before. 

Ultimately, trust comes from predictability. For anything tied to a studio’s revenue stream, that standard does not change. 

How does your platform help a small team behave like a global publisher without needing a massive back-office finance department? 

That's really the core value proposition of what we do, so I'll be direct about it: the merchant of record model was built for exactly this use case. When a two-person studio wants to sell globally - handling VAT in the EU, sales tax in the US, local payment methods in Southeast Asia - they don't have the resources to build and maintain that infrastructure. We handle all of it. 

What we're investing in now is making the experience of getting there faster and more developer-friendly. That means better SDKs, cleaner APIs, checkout components that let a small team ship a world-class web store without a dedicated front-end engineer. The goal is that a small studio should be able to look at our platform and feel like they have the same tools IBM would expect - because increasingly, they do.