Appcharge vs. a Single-PSP Setup: What Two Live Tests Showed, and What Fits Your Game
Between May and June 2026, a top-grossing casual publisher ran Appcharge head-to-head against a leading PSP on its own North American web store traffic. Transaction success rate rose 5.28%.
Most studios never run that test. Household name PSPs are already the generic answer to "how do we take payments online" — familiar, well-documented, fast for an engineering team to integrate. Mobile game teams looking to sell virtual items to players outside of iOS or Android billing often follow the same path.
That default carries a real cost, and it starts with what happens the moment a single payment fails.
Single-PSP Setups Are Excellent at What They’re Built For
The biggest general-purpose PSPs offer some of the most reliable payment processors in the world and are used across nearly every industry. Their reach, uptime, and developer experience are strong, and there's no reason to pretend otherwise.
That reach comes from staying horizontal: broad enough banking relationships to run a checkout in most markets, built to serve furniture stores and software subscriptions as well as games. The kind of granular, purchase-specific optimization a mobile game's web store needs — several providers routing around each other's failures, checkout flows tested against real player behavior — was never the design goal for a company built to be the one processor underneath everything.
One Provider vs. a Network
The choice between a single-PSP setup versus a network of PSPs shows up most clearly the moment a single transaction goes wrong. A payment service provider runs transactions through its own connection to the card networks. If an attempt is declined for a fixable reason, such as a temporary issuer glitch or a rail timeout, a second route isn't there by default. Adding a second route means sourcing another processor, signing your own contract with it, and managing the setup yourself.
A Merchant of Record built on multi-PSP orchestration (hey 👋) solves that failure differently.
The PSPs come already integrated, so a studio doesn't source or manage processor contracts itself. We route payments across them using rules based on approval data, and if the first attempt fails for a fixable reason, we retry it through another provider automatically.
That difference stops being abstract once volume is real. Appcharge processes more than $1.3 billion in annualized DTC transaction volume. A two to three percentage-point swing in approval rate on that base is worth $26 to $39 million a year: payments that used to fail, now going through. That range sits below the lifts measured in the two deployments that follow.
Run the same math on a single studio doing $300 million in DTC a year, a plausible run rate for a top-grossing title. Two to three points there is $6 to $9 million, recovered from players who were already trying to pay.
Two recent, measured deployments show the same pattern holding in practice, not just on paper.
The publisher from the top of this piece is one of them: a top-grossing casual publisher, running Appcharge head-to-head against a leading single-PSP setup on its own North American web store traffic between May and June 2026. Transaction success rate rose 5.28%.
A second, separate publisher, one of the largest in casual gaming, saw transaction success rate rise 6.40% after we optimized PSP routing specifically for its Apple Pay traffic, in a July–August 2026 test on its US web store. Same mechanism as the diagram above: a payment that used to have one shot now has several, routed toward whichever provider is likeliest to approve it.
Neither number is a projection or an illustrative round figure. Both are measured results from studios already live on Appcharge, comparing real outcomes before and after, on their own traffic.
Checkout Templates Built to Be Tested
Approval rate is one lever. It's not the only place a single, one-size-fits-all checkout costs a mobile game money.
Big PSPs standardize their checkout UX: one flow, largely fixed, regardless of who's paying or what they've paid with before. Mobile games with sophisticated cohorts of players at different price points need greater flexibility and customization.
We don't run one checkout flow and hope it converts. We test specific hypotheses about what a player actually needs at the moment of paying, template by template, game by game, and let real conversion data decide which one is right.
One test, built to increase first-time deposits (FTDs) specifically, compared two ways of presenting the same purchase: order details expanded, showing the full breakdown of what's being bought, against the same screen collapsed to a single line. A first-time payer doesn't carry the trust a returning one does, and how much detail actually earns that trust turns out to be testable, not a guess.
A second test targeted repeat purchases. A standard checkout, showing every payment method at once with the card form already open, ran against a version built around a player's last payment method: one prominent Apple Pay button up front, with a plain link to switch if they want something else. A returning player who paid with Apple Pay last time doesn't need four other options in the way to get through the flow faster the second time.
Running tests like these, template by template, against real conversion data is the kind of granular, purchase-specific optimization that makes sense for a company built around mobile game payments. For a checkout built to handle everything from grocery delivery to enterprise software, it's a lower priority.
That testing shows up in the aggregate numbers: template-level A/B testing across our checkout has driven a 7% lift in conversion, with players reaching a 92% completion rate within 30 days of a template going live. That's what happens when a checkout keeps testing itself against real player behavior.
Who Carries the Merchant of Record Liability
None of this matters much if a studio still has to stitch together everything else itself. Processing a payment and serving as its Merchant of Record are two different jobs. A general-purpose PSP does the former. Everything else - Merchant of Record coverage, automated tax handling, fraud tooling and dispute operations, revenue reporting - gets sourced separately. Another service, another integration, another vendor to reconcile, stacked on top of the base processing relationship.
That gap shows up on the bill, not just the org chart. Each add-on carries its own line item, and line items compound. A processing rate that looks competitive on its own can turn into a materially higher total cost once every piece a studio actually needs to run compliant, protected DTC billing is stacked back on top of it.
We build it in, as one vendor and one bill. Tax registration, remittance, fraud tooling, and chargeback handling all run through the same infrastructure that makes our routing possible, so a studio never has to register anywhere itself or stitch together a separate Merchant of Record layer on top of whoever processes the payment.
Where Routing is Heading
The next generation of our routing picks the best provider for each payment, adjusting in real time to send it where it's most likely to be approved.
Today, routing is rule-based. We track approval rates for every provider, broken down by card (BIN, issuer, brand), amount, geography, currency, payment method and cost, and use what we learn to set rules that send each kind of payment to the provider that performs best for it.
The next step builds on that foundation. It looks at each payment individually, adjusts in real time to approval rates, response times and provider availability, and weighs cost against the likelihood of approval.
Take a hypothetical. A player in the US taps Apple Pay in a game’s web store, using a Chase card. Here is what happens next:
- We receive the payment and choose which PSP to send it to.
- That PSP passes it through the card network to Chase, the issuer.
- Chase approves or declines. The answer travels back the same way, and the player sees a confirmation or an error.
Say PSP A is the stronger processor across all its traffic. But on Chase cards, it approves 87 of every 100 payments, while PSP B approves 90. Maybe A’s connection to that issuer is thinner. Maybe the issuer’s risk model reads A’s traffic differently. Whatever the cause, a single PSP never sees the gap. It sees only its own 87.
With approval data from every PSP in one place, we do see it, so at step 1 we send Chase Apple Pay payments to PSP B. Because we hold the payment data rather than any single PSP, the same payment can go to either. Across 100,000 of those payments, that is 3,000 more approved. At a $10 average purchase, it’s $30,000 recovered. As routing gets smarter, that choice can also shift in real time, for example when a provider slows down or goes offline.
That data-driven routing layer is still being built. Cross-PSP retry when a payment fails is live today; matching each transaction to its best provider before the first attempt, using the accumulated pattern, is the next step
Five Questions Worth Asking, Whoever You Use
A general purpose, single PSP setup remains a strong choice for most of what businesses use it for. A mobile game's web store or in-game linkouts is a different shape of problem: high-frequency transactions at volume, where a fraction of a percentage point in approval rate adds up to real revenue.
You don't need to be evaluating a switch to find out where you stand. Five questions, put to whatever processor you're running today, do it:
How does your processor decide where each payment goes – does it route each transaction to the provider most likely to approve it, based on the card, amount, market and payment method, or does every payment take the same path? Owning the data it is what makes it possible to learn which provider actually performs best for a given payment method, market, and issuer — a pattern no single processor can see from inside its own numbers.
When a payment is declined for a fixable reason — a temporary issuer glitch, a rail timeout — does anything retry it through a different provider, or is that one attempt the only shot the transaction gets? This is the single biggest lever on approval rate, and at real volume, a fraction of a point is real money.
Does your checkout test different templates against real player behavior, or does every player see the same fixed flow regardless of what's actually converting? A payment method surfaced in the right order, or shown one at a time instead of all at once, is a conversion lever most checkouts never touch.
Is Merchant of Record coverage — tax registration, remittance, chargeback handling — built into what you're already paying for, or is it a separate line item stacked on top? Line items compound. A competitive headline rate can hide a much higher total cost once everything a studio actually needs is added back in.
Would you get more from a specialist vendor? Would you benefit more from the personal touch and support of a specialist vendor than from a global giant? An enormous PSP builds one product for every kind of business. That's its strength. It also means the product holds its shape for everyone.
Anecdotally, one top-grossing studio we now work with wanted to customize its background image behind a checkout hosted by its former PSP; they wouldn’t accommodate this request.
We're built for mobile games. Our team works with your designers on a checkout that looks like an extension of your game, and tunes it from your own payment data.
