The second top-up in one session is where
a wallet-model store earns the third, or loses it.
For free-to-play publishers, subscription MMOs, own-store wallet models and cloud-gaming platforms, the payment layer has to recognise a repeat top-up as the same buyer within seconds of the last one. When it does not, the third and fourth in-session charges drop out silently, and one fixed dispute fee wipes out the margin a two-dollar item earned.
- CheckoutBuyer selects a method and confirms
- AuthorisationIssuing bank approves or declines in real time
- CaptureAuthorised amount is submitted for clearing
- SettlementFunds settle from the issuer to the acquirer
- PayoutMerchant receives cleared funds
Licensed Austrian Payment Service Provider and Acquirer with 25+ years of operation
Four things that happen to a wallet-model store between one quarterly review and the next.
None of the four is on a provider dashboard, and none of the four is a launch-day failure. Each one is what a Head of Payments running a wallet-model store already recognises from their last quarter.
A fixed dispute fee wipes out the margin from several successful charges around it.
Structural causeThe dispute cost is sized against a merchant profile with larger ticket sizes than a two-dollar or five-dollar in-game purchase, so the fixed cost lands on a base that cannot absorb it.
Commercial consequenceSuccessful micro-transactions are silently cancelled out on the P&L by a single chargeback fee against one of them, and the mismatch shows up as unexplained margin drift rather than as a dispute line.
The second and third top-up in one session drop out silently.
Structural causeFull checkout friction is reintroduced on every repeat purchase inside the same session, instead of the payment layer recognising the player from the top-up that closed seconds ago.
Commercial consequenceIn-session spend collapses at the point the player is most engaged, and the loss surfaces as a conversion-per-active-player figure that no single transaction log explains.
Approval rates fall on the players who top up most often.
Structural causeRepeated small charges against the same card are treated as isolated unknown risk events instead of a coherent buying pattern, so the network scores them lower the more often the buyer returns.
Commercial consequenceAuthorisation performance degrades on the busiest card-holder cohort, and the platform ends up with worse approval numbers on its best players than on its casual ones.
Subscription revenue vanishes between renewals, with no failed charge to show for it.
Structural causeStored card details expire between renewals and the payment layer waits for a decline to surface the problem instead of refreshing the credential in the vault ahead of the charge.
Commercial consequenceA whole billing period of revenue goes silently missing on a cohort that never received a decline message and therefore never opened a support case.
These four are the state of play for a wallet-model store on a standard payment stack. The next question is what a payment setup built for this specific shape would have to hold on all four at once.
A payment setup built for micro-ticket frequency answers three questions before the first live charge.
The four business realities above sit on three different time axes: seconds inside a session, months across renewal cycles, and the hours of a season launch. Any payment setup meant for a wallet-model store has to answer for each axis on its own. Below are the three questions to take into the next provider conversation.
Recognition beyond the first top-up
The vault has to recognise a repeat buyer within the same session and across sessions, and that recognition has to hold up in the authorisation rate at high frequency, not just in the checkout UI.
Recognition inside the checkout is the easy half. A stored token that skips card re-entry closes the visible friction, and any modern gateway can show that. The harder half is what the network sees. Repeated small charges against the same tokenised card have to be presented as one coherent buying pattern rather than as separate unknown events, or the approval rate quietly drops on the busiest cohort.
That difference sits in how the payment setup passes the token, how it schedules retries, and how it declares the buying context to the acquirer. It is not a checkbox on a data sheet. A provider that treats vaulting and network representation as two sides of the same mechanism will describe both in the same sentence; one that treats them as separate features will not.
Ask any provider: how does your vault represent a returning player to the network on the second, third and fourth charge inside one session, and what happens to the authorisation rate on that cohort compared to a first-time buyer?
Human-underwritten stability, on the record
Human-underwritten stability. No algorithmic freezes. Every account decision has a person behind it and a documented reason, especially in the hours around a season launch.
A live-service publisher does not need a provider that promises nothing unusual will ever happen. It needs a provider whose response to something unusual is a call from a named person, not a status page and a support ticket. That distinction only holds up if underwriting decisions on complex, high-frequency profiles are made by people and recorded, rather than produced silently by a scoring system.
The test is what happens the day a spike arrives that the model has not seen. Under human underwriting, the account gets a conversation and a decision that leaves a trail. Under an algorithmic freeze, the account gets stopped and the reason has to be reconstructed afterwards. Season launches make the difference expensive; live-service cadences make it recurring.
Put this to any provider: when something unusual happens on my account during a season launch, who calls whom, and where is the decision written down?
Recurring cycles kept whole
Stored credentials are refreshed inside the vault before a renewal fails, and reserve and payout terms are set on the record upfront instead of adjusted mid-cycle.
A subscription MMO or a live-service publisher loses a full billing period silently when a stored card expires between renewals and the setup waits for the decline to surface it. The fix is a vault that refreshes those credentials against the network on its own schedule, so the renewal cycle reaches the charge with a working card rather than an expired one that no one has looked at.
The second half of the same question is what the finance side can plan against. Reserve terms and payout timing that are agreed on the record at onboarding stay stable through a launch; the same terms produced by an automated system in the middle of a launch do not. A payment setup that keeps the renewal cycle whole keeps both halves in one contract.
The question for each provider: how does your vault refresh an expiring credential before a renewal charge fails, and where are my reserve and payout terms written down before the first live transaction?
Three questions define what a setup for this shape has to hold. The next section shows how DaoPay holds them across the three layers of the payment stack.
On a wallet-model store, payments don’t break inside a layer. They break at the handover between two.
Each of the four business realities above sits on a different handover in the payment stack. A repeat top-up drops out at the acceptance-to-processing handover. Approval rates fall at the processing-to-network handover. A dispute fee erodes margin at the processing-to-reconciliation handover. A renewal cycle disappears at the vault-to-billing handover. The three layers below show where DaoPay holds each of them.
- Checkout
- Authorisation
- Capture
- Settlement
- Payout
- Finance ops
- Layer 1
ACCEPTANCE
Local payment methods, cards, wallets, tokenisationThe methods your players use in each country, in the right currency and with the right authentication flow.
- Handover 1 · Acceptance → ProcessingWhere routing decisions set your capture rate
- Layer 2
PROCESSING
Routing, retries, capture, network communicationRouting per transaction across acquirers, with cascading retries when one path fails.
- Handover 2 · Processing → ReconciliationWhere settlement files meet your ledger, usually left to Finance
- Layer 3
RECONCILIATION & PAYOUT
Settlement matching, fee accounting, payout schedulingOne reconciliation feed across all methods and acquirers, with payouts on an agreed schedule.
Which layer owns each journey station, and the two handovers where multi-provider stacks break.
Not sure if online games fits your setup?
We built one page for each industry we know how to serve. Pick the one closest to your business, or use the visual guide below to see where your business fits.
Prefer a head start?Pick your industry below to see the journey built for it.
Check the fit for your wallet-model store before the integration, not after it.
Five short questions, a human read on the other side, three possible answers you can plan around. No integration work happens until the currency classification and the launch cadence sit right on both sides.
Answer what you can, and anything you are unsure of can stay blank. Nothing is sent until you press the button.
Four people will read this decision before it is signed, and each one reads a different part of it.
Finance looks at the fee side of a micro-ticket P&L, Technology at the vault and the callback, Compliance at the channel split, Operations at the second top-up in one session. Below is the short answer for each.
How does DaoPay represent a returning player to the network on the second, third and fourth charge inside one session?
The vault carries a network-side identifier that remains stable across charges inside a session, not just a merchant-side token that closes the checkout friction.
The visible half is checkout recognition: the stored token skips the card entry field on the second top-up. The invisible half is network representation: the same buyer arrives at the acquirer already flagged as a returning tokenised profile, with the previous authorisation still readable in the context. Repeated small charges are presented as one coherent pattern rather than three isolated risk events.
Concretely, this means the token, the buyer profile identifier and the session context are passed together on each authorisation call inside the same session, and the retry schedule on a soft decline is set to give the network time to update its own view rather than to hammer the same card. Approval performance on the busiest cohort holds instead of degrading.
Ask any provider: on the second, third and fourth charge inside one session, what does your authorisation call actually pass to the network, and where does the retry schedule sit?
What signal reaches you before a cardholder query becomes a chargeback?
A pre-dispute notification path with the participating networks lets a suspicious transaction be resolved before it converts into a formal chargeback.
The pre-dispute layer sits between the moment a cardholder queries a charge and the moment their issuer opens a chargeback case. On the participating networks, a notification reaches the merchant early enough to review the transaction, contact the player, refund on the merchant’s own terms, or submit compelling evidence, before a formal dispute enters the count that scheme monitoring watches.
This matters most on a wallet-model store, where a single unresolved dispute against a two-dollar item carries a fixed cost that no single successful charge around it can absorb. Catching that transaction upstream of the formal case is a margin-preserving mechanic, not a customer-service one.
A useful test for any provider: which pre-dispute networks are you connected to, and how quickly does the notification reach me after the cardholder query?
What does "human-underwritten stability, on the record" mean when something unusual happens to my account during a launch?
A named underwriter on the file, a written decision trail, and a phone call rather than a status page when the numbers move.
Every merchant onboarded through the DaoPay portfolio has a named person on the underwriting file. When traffic, volume or basket composition moves outside the profile the file already documents, that person opens a conversation: a call, a documented question, a written decision, instead of a scoring model closing the account and leaving the reason to be reconstructed afterwards. The trail is on file, not in a log.
For a live-service publisher, this is the difference between a season launch that keeps running while the profile is re-evaluated and a season launch that stops while someone tries to reach support. The mechanic is operational, not marketing: a person, a phone number, a written record, applied to complex portfolios on the record.
Worth asking any provider: who is the named person on my file, and how is a decision on my account documented on your side?
The pack for the meeting.
Fill in your details and the Internal Review Pack opens straight away as a PDF in a new tab: a short document written for the four people in the building who will read this decision before it is signed. Fee structure, callback contract, channel split, vault mechanics, on one file.