Kwai Clone Script: How Coins, Wallets and Creator Payouts Work

Most writing about creator payouts stops at the diagram. Viewer pays, platform takes a cut, creator withdraws. That diagram is true and it is useless, because every hard problem in a creator economy build lives one level below it: in which table the balance sits, in what unit it is denominated, which admin screen approves its release, and what happens to all of it when a scheduled job does not run.

This post works at that level. It walks the money plumbing of a documented short-video platform build – the one behind our Kwai clone – from the moment a viewer taps a coin package to the moment an operator approves a cash payout, and it names the parts that are configuration, the parts that are cron, and the parts that are still open. If you are costing a creator payout system, the useful information is not the list of monetization options. It is the shape of the ledger underneath them.

A note on scope: this is the creator side of the economy. The seller and registered-business side of commerce runs on its own balance and its own withdrawal queue, and it is a separate argument. Everything below concerns money that flows to a creator.

Why does one creator need three separate balances?

This is the single most important structural fact about the build and the one founders consistently discover late. A creator on this platform can be holding value in three distinct places at the same time, and they are not interchangeable.

The first is users.coin_wallet, an integer column on the user record. This is the spending wallet. It holds coins the person bought, and because every user is potentially a creator, a creator has one too. Coins here are money you have already collected and not yet delivered anything for.

The second is the creator wallet, its own table with a one-to-one relationship to the user record, keyed on creator_id, holding a balance as a decimal with two places. This is earned coins – what gifts, unlocks and subscriptions credited. It is the balance that redeems to cash through the coin withdrawal flow.

The third is the creator fund wallet, again one-to-one with the user, but denominated as a decimal with four places and carrying its own total_earned and total_withdrawn running totals, plus its own transaction table with a credit/debit type enum. This is not coins. This is fund money, in currency, paid out of an operator-funded pool.

Three balances, three units of account – integer coins, two-decimal coins, four-decimal currency – and no shared ledger between them. That is not a flaw to fix before launch; it is the design, and it is a reasonable one, because the three represent genuinely different kinds of obligation. But it means that “what does this creator have” is a three-query question, that your finance reporting has to convert before it can sum, and that rounding policy is a decision you own rather than one the schema makes for you.

How does a viewer’s payment become a creator’s coin?

The documented path has two clean halves, and confusing them is the root of most bad revenue forecasts.

Half one is purchase. The viewer picks a coin package from the admin-defined package table – each row is a coin quantity, a price, a currency and an active flag – and pays through Stripe, PayPal or in-app purchase. On success the coin wallet is credited. Real money has moved into your account. No creator has earned anything, and from an accounting standpoint you now hold a deferred obligation, not revenue.

Half two is spend. The viewer sends a gift on a post or during a live stream, and the creator’s wallet is credited with the gift’s coin value, with the operator’s commission applied if one is configured. Or the viewer unlocks a pay-per-view post: the creator sets is_paid and an unlock_price in coins, the unlock is recorded, and the creator receives the unlock price less commission. Or the viewer subscribes to a plan priced in coins. In every case the coins move from one wallet to another and your real-money position does not change at all. You banked the cash in half one.

Tips are the exception worth memorizing, because they skip the coin layer entirely. A tip is real money, initiated and verified against the payment gateway directly, with a commission percentage applied, and logged in the generic payment transaction table. Gifts are a coin event. Tips are a card event. They look identical in the app and they are completely different on your books.

Where does the operator’s commission actually live?

In the global settings row, as named columns. The documented settings schema includes a subscription commission percent, a pay-per-view commission rate, a tip commission percent and a creator product commission percent, alongside a coin value that defines what one coin represents in real currency and a minimum redeem coin threshold.

That placement is the whole point. Changing your platform’s take is an admin form submission, not a code change, not a deploy, not a release window. You can run a lower subscription commission for a launch cohort and raise it later. You can tune pay-per-view independently of tips. None of it requires an engineer.

One honest gap to check on your own build: the gift path. The feature documentation states that commission on gift revenue is configurable, and the gift requirement says the creator wallet is credited “with admin commission if configured.” But the documented settings column list names those four percentages – subscription, pay-per-view, tip, creator product – and does not name a separate gift commission column. Before you model gift revenue, confirm where your installation reads the gift cut from. It is a five-minute check that protects a forecast.

What does the app store take before you take anything?

This is the number most creator-economy business models quietly omit, so here it is plainly.

Coin packages can be bought through in-app purchase, and in-app subscriptions are supported through a purchase management layer in the mobile app. When a coin package is sold that way, the mobile platform’s commission comes off the top, before the money reaches you. Your commission percentage then applies to what arrives – not to the price the viewer saw.

So a commission setting of any given percentage does not describe your margin on an in-app purchase. It describes your share of the residue after the store’s cut. The same coin package sold through the web app over a card gateway nets you materially more, because only the gateway’s processing fee intervenes. Nothing in the platform hides this from you, and nothing in the platform solves it either – the settings table lets you enable or disable in-app purchase, PayPal, Stripe and other gateways independently, which means channel mix is a lever you hold. Founders who model one blended take rate across app and web will be wrong in the direction that hurts.

How does the creator fund differ from the gift wallet?

Structurally, almost completely. The creator fund is the only stream where the operator is the payer rather than the intermediary, and it has six tables of its own to prove it.

There is a wallet table holding balance, total earned and total withdrawn. A transaction table recording credits and debits against that wallet with a reference date. An applications table, because fund access is applied for and reviewed – status moves through pending, approved, rejected and paused, with an admin remarks field and a reviewed timestamp. A withdrawals table with its own status enum of pending, paid and rejected, plus method, payout details and admin remarks. A daily stats table recording qualified views, qualified watch time in seconds, a pool share percentage, an earned amount and a calculation status of calculated, paid or error. And a settings table holding the pool amount per period, the minimum watch duration in seconds that makes a view qualify, and the minimum follower and view requirements for eligibility.

Read that list again and notice what it tells you about operating cost. The fund is not a feature you switch on. It is a recurring budget you fund, an eligibility policy you set, an application queue a human reviews, and a daily calculation you have to confirm ran. The schema even anticipates failure with an error status on the daily stat row. Every creator fund has those obligations; this one is at least explicit about them.

Which withdrawal door does a creator actually use?

Two doors, and they are genuinely separate systems. A founder who assumes one payout queue will build the wrong operations rota.

The coin door converts earned coins to cash. The creator submits a withdrawal request naming a gateway and a payout account; the request row records the coin count, the conversion value and the cash amount; admin lists pending withdrawals and either completes or rejects each one; and the available payout methods come from an admin-managed gateway table, so PayPal, a regional wallet or a bank route are rows you add rather than code you ship. Status on that table is a small integer: pending, completed, rejected.

The fund door pays out currency that is already currency. The creator requests a fund withdrawal, it lands in the creator fund withdrawals table with method and payout details, and admin approves or rejects it from the creator fund management screens. Status there is a string enum: pending, paid, rejected.

Different tables, different status vocabularies, different admin screens, different units. Your support team needs to know which one a creator is asking about before they can answer, and your finance export needs to read both before it can tell you what you owe.

If you take one table from this post into a planning meeting, take this one. It lays the three-balance problem out as the operational decision it actually is, with both withdrawal routes side by side.

Dimension	Spending coin wallet	Creator coin wallet	Creator fund wallet
Where it lives	Column on the user record	Own table, one row per creator	Own table, one row per creator
Unit and precision	Integer coins	Coins, two decimals	Currency, four decimals
What credits it	Coin package purchase, rewarded ad, admin credit, signup bonus	Gifts, pay-per-view unlocks, coin subscriptions	Scheduled fund calculation against qualified views and watch time
Who funds it	The viewer	The viewer, less operator commission	The operator’s pool budget
Gate before earning	None	Creator role and status	Application reviewed and approved by admin
Withdrawal route	Not withdrawable – it is for spending	Coin withdrawal request, admin-managed gateway list	Fund withdrawal request, fund admin screens
Status vocabulary	Not applicable	Pending / completed / rejected	Pending / paid / rejected
Your accounting treatment	Deferred obligation, not revenue	Amount payable to creators	Committed pool spend

Why does a single switch matter more than any commission rate?

Because the settings table carries one flag that globally enables or disables creator withdrawal requests, and the feature documentation is explicit about why it exists: it lets an operator pause payouts, for instance during an audit or a policy change.

That is a genuinely valuable control. If you spot a coin exploit, a compromised account cluster or a gateway dispute, you want one action that stops money leaving while you investigate – not a scramble to disable gateways one at a time. Paired with the minimum redeem coin threshold, which keeps micro-payouts from flooding the queue, it is the right pair of blunt instruments for a small operations team.

It is also the control to write a runbook around, for two reasons. It is global, so pausing one suspect creator means pausing every creator. And it is silent to the people affected unless you tell them – a creator whose withdrawal button has stopped working does not know whether the platform is broken, has run out of money, or is investigating them, and all three guesses damage trust. Decide now who can flip it, what gets posted to creators within the hour, and what condition turns it back on. That decision costs nothing today and a great deal during an incident.

Which coins enter the economy without any cash coming in?

Three documented routes, and they matter because each one creates a payable obligation with no matching deposit.

Admin can credit coins directly to a user’s wallet from the admin panel. The settings table carries registration bonus fields, so new users can arrive holding coins. And rewarded video is supported in the mobile app: a viewer watches an ad and receives coins, with the platform keeping the margin between what the ad network pays and what the coins cost it.

Every one of those coins is spendable on a gift. Every gift credits a creator wallet. Every creator wallet balance is redeemable for cash. So a promotional coin you handed out for free can, three steps later, become a real cash payout request on your desk. That is not a bug – growth teams give away currency on purpose – but it has to be budgeted as marketing spend at the real coin value, with a cap, and reconciled against the pool of coins outstanding rather than against the coins you sold. Operators who track only purchased coins will understate their liability by exactly the amount they gave away.

What happens to payouts if a scheduled job does not run?

You lose a day of fund earnings calculation, and nothing retries it for you.

Native queue workers are explicitly out of scope on this build. Scheduled work is cron and scheduled commands only, and the creator fund calculation is one of those daily commands, sitting alongside story expiry, notification cleanup and the daily active user count. There is no job queue holding a failed run, no automatic backoff, no dead-letter record to replay.

For most of what cron does here, a missed night is cosmetic. For the fund calculation it is not, because that command is what writes the daily stat rows that creators see as earnings. A silent cron failure looks to a creator like the platform decided they earned nothing yesterday. So monitor that specific command’s completion, not just server uptime, and decide in advance whether a missed day is recalculated or written off – the daily stat table’s error status gives you somewhere to record the answer. If you want the broader picture of how scheduled work is organized on platforms like this, our write-up on background processing for creator platforms covers the trade-off between cron and a real queue.

What is not in the box yet on the money path?

On a page about payouts this is the most useful section, so it is not buried. The security assessment documentation for this platform names several money-path controls as recommendations and hardening items rather than as shipped behavior. Treat them as your pre-launch list.

Rate limiting. The assessment records that rate limiting is not explicitly present in the route configuration, and recommends adding throttle middleware per route and per address or user. On payment and withdrawal endpoints, that is not a nice-to-have.

Payment webhook signature verification and idempotency. Both appear as mitigations against webhook forgery and duplicated payment completion, and both sit on the pre-assessment hardening checklist. Until verification is in place, an unauthenticated callback is a route to credited coins you were never paid for.

An audit record of payout approvals. The assessment names unauthorized approval and payout to the wrong account as the withdrawal risks, and lists admin authentication, an audit log and payout detail confirmation as the mitigations. An audit trail answering “who approved this payout, when, and to which account” is the control that makes a disputed payout resolvable. Optional two-factor authentication for admin sits in the same recommendation set.

Atomicity on coin spends. The assessment names race conditions and negative balances as risks on buying coins, sending gifts, unlocking pay-per-view content and subscribing, with database transactions and balance checks before debit as the mitigation. Verify that behavior on your own build with concurrent requests before you trust a balance.

One more honest absence, from the product requirements rather than the security review: a built-in analytics dashboard for creators is out of scope beyond the creator fund dashboard and the ad statistics. Creators will ask for earnings analytics. Plan for that conversation.

Founder Decision Signals

A short set of questions that reliably predict whether a creator payout build goes smoothly, drawn from what the data model actually forces you to decide.

Can you name your coin value in real currency right now? If not, you cannot set the minimum redeem threshold, you cannot price packages coherently, and you cannot value the coins you plan to give away. This is the first number, not a later one.

Do you have someone who reviews applications and approves payouts? The fund has an application queue and both withdrawal paths require admin action. These are staffed processes with a service expectation attached. If no name goes next to them, the queue becomes your worst creator-relations problem by month two.

Is your launch channel the app or the web? This decides whether the store’s cut sits inside your unit economics from day one. Launching app-first with web-equivalent margin assumptions is the most common modeling error in this category.

Are you running the creator fund in the first quarter? It is a committed budget plus a review queue plus a monitored daily job. Gifts, tips, subscriptions and pay-per-view need none of that. Launching the fund later is a defensible sequencing choice, and the tables will be waiting.

Who flips the withdrawal switch, and what do creators get told? Answer this before you need it. Every operator eventually needs it.

Common Creator Payout Mistakes to Avoid

Counting coin sales as revenue. A coin purchase is cash in hand against an obligation not yet discharged. Recognizing it as revenue on purchase flatters early months and creates a hole later when payouts land.

Modeling one blended take rate. Four separate commission percentages exist precisely because the streams behave differently, and the store cut only applies to one purchase channel. One blended number is wrong everywhere at once.

Treating the fund as a feature toggle. It is a budget, a policy, a queue and a monitored job. Turning it on without funding the pool produces approved creators earning nothing, which is worse than never having offered it.

Giving away coins without capping the liability. Signup bonuses, admin credits and rewarded-ad coins all convert into withdrawable creator balances downstream. Cap them and value them at the real coin rate.

Launching without webhook signature verification. It is on the hardening checklist for a reason. An unverified payment callback is the cheapest possible attack on a coin economy.

Assuming one payout queue. Two withdrawal tables, two status vocabularies, two admin surfaces. Support scripts and finance exports that know about only one will mislead the people reading them.

Promising creators earnings analytics you do not have. Creator analytics dashboards are out of scope beyond the fund dashboard and ad stats. Say so early rather than discovering it in a creator onboarding call.

How a Ready-Made Foundation Fits a Creator Payout Build

Everything described above is schema, admin screens, settings columns and scheduled commands. None of it is clever. All of it is weeks of work, and most of it is work you cannot shortcut, because a payout system that is 90 percent correct is a payout system that loses money in a direction you will not notice for a quarter.

That is the actual case for starting from a built foundation on this particular layer. A Kwai clone script gives you the coin package table, the three wallets, the gift and unlock and subscription credit paths, both withdrawal queues, the admin-managed gateway list, the six creator fund tables, the commission settings and the global payout switch already wired together and already consistent with each other. Your engineering time goes into the decisions that are yours – coin value, commission strategy, eligibility policy, payout service levels, the hardening items – rather than into rebuilding a ledger that has a known shape.

At Miracuves we build on this foundation as a Flutter application against a Laravel and MySQL backend, with live streaming through Zego, and we are deliberate about the boundary between what ships and what is an open item – which is why the hardening list above is in this post rather than in a footnote. Our wider video content platform solutions cover the surrounding surfaces, and the media and entertainment industry practice is where the payout and compliance questions get worked through with founders before a single commission percentage is set.

The honest framing of a ready-made foundation on a money path is this: it removes the invention, not the judgment. The tables are decided. The percentages, the policy and the controls are still yours, and they should be.

Final Thoughts

A creator payout economy is not a feature list. It is a ledger with three balances, two withdrawal doors, a settings row that defines your margin, a daily job that nothing retries, and a short list of security controls that have to be closed before real money touches it. Read in that order, a Kwai clone script is less a collection of monetization options and more a set of decisions already narrowed down to the ones worth your time.

The founders who do well here are the ones who treat the coin wallet as a liability from the first week, who know which channel their coins are sold through before they quote a margin, who staff the approval queues rather than discovering them, and who close the hardening list instead of launching past it. None of that is difficult. All of it is easier to do before launch than after a disputed payout.

If you are costing a creator payout layer and want the plumbing walked through against your own commission strategy, payout markets and launch channel, that is a conversation worth having before the first setting is saved.

FAQs

<!– wp:rank-math/faq-block {"questions":[{"id":"faq-question-17612301","title":"How many separate wallets does one creator have?","content":"

Three, and they are not interchangeable. The spending coin wallet is an integer column on the user record and holds coins the person bought. The creator coin wallet is its own table and holds earned coins from gifts, pay-per-view unlocks and coin subscriptions. The creator fund wallet is a third table, denominated in currency rather than coins, and holds fund payouts. Only the second and third are withdrawable, and each uses a different withdrawal flow with a different admin queue and a different status vocabulary.

“,”visible”:true},{“id”:”faq-question-17612302″,”title”:”Is selling coins the same as earning revenue?”,”content”:”

No. A coin purchase puts real money in your account against an obligation you have not discharged yet, because those coins are still spendable on gifts, unlocks and subscriptions that will credit creator balances later. Recognizing coin sales as revenue on purchase makes early months look better than they are and creates a shortfall when withdrawal requests arrive. Treat the outstanding coin balance as a liability valued at your configured coin value.

“,”visible”:true},{“id”:”faq-question-17612303″,”title”:”Where are platform commission percentages configured?”,”content”:”

In the global settings row, as named columns: a subscription commission percent, a pay-per-view commission rate, a tip commission percent and a creator product commission percent, alongside the coin value and the minimum redeem coin threshold. Because they are settings rather than code, changing your take rate is an admin action and not a deployment. One item to verify on your own installation is where the gift commission is read from, since the documented settings column list names those four percentages and does not name a separate gift column.

“,”visible”:true},{“id”:”faq-question-17612304″,”title”:”Does a platform commission mean that percentage of margin?”,”content”:”

Not on an in-app purchase. Coin packages and in-app subscriptions bought through the mobile stores have the store’s commission deducted before the money reaches you, so your configured percentage applies to the remainder rather than to the price the viewer paid. The same package sold through the web app over a card gateway nets materially more. Because the settings table lets you enable gateways independently, channel mix is a lever you control, but it has to be modeled per channel rather than blended.

“,”visible”:true},{“id”:”faq-question-17612305″,”title”:”What does running a creator fund actually commit an operator to?”,”content”:”

A funded pool amount per period, an eligibility policy covering minimum followers, minimum views and the minimum watch duration that makes a view qualify, a human reviewing an application queue whose statuses run pending, approved, rejected and paused, a withdrawal queue to approve, and a daily scheduled calculation that has to be monitored. Six tables exist to support that, including a daily stats table with an error status. It is a budget and a staffed process, not a toggle.

“,”visible”:true},{“id”:”faq-question-17612306″,”title”:”Can an operator pause creator payouts?”,”content”:”

Yes. The settings table carries a single flag that globally enables or disables creator withdrawal requests, documented as a way to pause payouts during an audit or policy change, and a minimum redeem coin threshold that keeps very small payout requests out of the queue. The switch is global, so it pauses every creator rather than a single account, and creators are not told why their withdrawal button stopped working unless you tell them. Agree in advance who can flip it and what gets communicated.

“,”visible”:true},{“id”:”faq-question-17612307″,”title”:”What security work is still open on the payment path?”,”content”:”

The security assessment documentation lists several items as recommendations rather than shipped behavior, and they should be treated as a pre-launch checklist on a money path. Rate limiting is recorded as not explicitly present in the route configuration. Payment webhook signature verification and idempotency on payment completion appear as hardening items. An audit log of payout approvals, confirmation of payout details and optional two-factor authentication for admin are listed as the mitigations for unauthorized approval and payout to the wrong account. Database transactions and balance checks against double spend and negative balances are also named as mitigations to verify.

“,”visible”:true},{“id”:”faq-question-17612308″,”title”:”Do creators get an earnings analytics dashboard?”,”content”:”

Not beyond the creator fund dashboard and the creator ad statistics. A built-in analytics dashboard for creators is listed as out of scope in the product requirements. Creators will ask for earnings analytics, so it is better to set that expectation during onboarding than to discover the gap after a creator has committed to the platform. The underlying data exists in the wallet, transaction, daily stat and ad stat tables if you choose to build reporting on top of it.

“,”visible”:true}]} –>