Adding sweeps to an existing platform

What changes when a single-currency product becomes a two-currency one: the ledger, the entry route, the payout path, and what you can keep exactly as it is.

What you already have that still works

Most of what you have built stays exactly as it is. That is not reassurance, it is the reason the API integration exists: it supplies the catalogue, the launch layer and virtual-currency support to a platform that already holds its own players and its own ledger.

What you keep

None of this is rebuilt. The API integration exists for operators in exactly this position.

  • Player accounts and identityYour accounts stay yours. Nothing about the sweeps model requires a second account system beside the one you have.
  • Front end, lobby and session handlingWhat a player sees and how a session is held stay your product decisions, the same as they are today.
  • Existing content relationshipsContracts you hold with studios directly are not disturbed by adding a catalogue alongside them.
  • Your reporting and back officeYou keep working in the tools your team already knows. What changes is what the numbers underneath them mean.

What changes

One thing, and it is not a small one.

  • The ledgerA ledger built for one currency has to represent two, kept apart at every write rather than distinguished by a column. That is a change to how a transaction is recorded, not a field added to it.

What you take on

Four obligations you do not have today, each belonging to somebody on your side from the day you launch.

  • A free entry route that has to keep workingNot a page in the terms. A route a player can actually use, running as long as the product runs.
  • Per-state access controlRegistration, play and redemption gated by state, with the rules set somewhere and applied somewhere.
  • Verification before value leavesA check at redemption that you perform, on a player who until now never had to prove who they were.
  • Acquiring underwritten differentlyYour existing processing was underwritten for the product you had. A two-currency product with redeemable value is not that product, and the conversation with your acquirer is a new one.

The one thing that has to change

The ledger. A system built to hold one balance per player has to hold two, kept apart at every write rather than distinguished by a column somebody remembers to set. How that separation is designed is the subject of the dual-currency wallet; what follows is what it costs to retrofit rather than to build.

  • Where currency is captured. Every write that touches a balance has to say which balance, and that includes the ones written by code nobody has opened in two years.
  • What happens to history. Transactions recorded before the split have exactly one honest interpretation, and deciding it once is cheaper than deciding it per report.
  • Why two stores and a nightly reconciliation is the arrangement this model cannot have. Separation that is true in the morning and true again at midnight is not separation.

The question is not whether your ledger can store a second number. It is whether every path that writes to it can be made to say which one it meant.

What you are taking on that you did not have

Four obligations arrive with the model. None of them is a feature, and each belongs to somebody on your side rather than to a supplier.

  • A free entry route. It has to be usable rather than documented, and it has to keep working for as long as the product does — what makes a free route real is the whole subject.
  • Per-state access control. Registration, play and redemption gated by state, with somebody holding the rules and something applying them: where that boundary falls.
  • Verification before value leaves. A check at redemption, performed by you on both routes — who verifies and when.
  • Acquiring underwritten for a different product. What you have today was underwritten for what you were. how underwriting reads this model is worth understanding before the conversation rather than during it.

An operator adding this model is not adding a feature to a product. They are entering a category with obligations attached, and the honest version of this page says so before the integration section rather than after it.

What the integration actually involves

The technical work is the smallest part of this and it is worth saying so plainly. Your platform calls us to launch a round; we call your wallet while it runs. That is the shape of it, and the reference is the getting-started guide rather than this page — a situation page that restates a protocol is a documentation page that will fall out of date.

Teams with a working ledger and a spare fortnight generally finish the wallet side in a few days. The part that takes longer is everything above: the separation decision, the free entry route, and whoever has to own the compliance obligations from launch onwards.

What this does not solve

  • It does not make you compliant. It gives you the controls; the obligations stay yours and the analysis is still one for counsel.
  • It does not give you an acquirer. Nothing on either route supplies the merchant account behind a coin purchase.
  • It does not tell you whether your existing players will play a sweeps product. That is a question about your audience, and nobody supplying software can answer it for you.

Is this worth doing

Two lists, and the right-hand one is longer because it is the one people skip. If more than one line on the right describes you, the answer is not now rather than no.

Worth doing

  • You run a product with real players and want a second model beside it rather than instead of it.
  • You hold your own ledger and have engineers who can change how a transaction is written.
  • Your commercial team can carry a compliance obligation that is genuinely new, rather than treating it as a feature ticket.
  • You are prepared for the acquiring conversation to be reopened from the start.

Not worth doing yet

  • Your ledger is a third-party system you cannot change, which makes the one thing that has to change the one thing you cannot do.
  • You want the sweeps model to solve a payments problem. It adds a payments problem.
  • Nobody on your side owns compliance, and the plan is to decide who does after launch.
  • The commercial case depends on your existing audience converting, and nothing has been done to find out whether it will.
  • You are mid-underwriting or mid-launch on something else, and this would be the second change in flight.

The capability split behind all of this — who holds what, on each route — is on the platform page, row by row.

Reviewed . Corrections are made visibly rather than silently.

Building from nothing rather than adding to something? The launch guide covers the ten steps and what each one waits on.