Cash mode
offerwalls and surveys pay into the wallet.

01Turning cash mode on

Console → Offerwalls and surveys → Offerwall and survey rewards are paid as: Points (3.1 behaviour) or Cash in the wallet (economy.offerwallRewardMode, default points).

• Cash mode needs both offerwallRewardMode = "cash" and the wallet switched on (wallet.enabled). While the wallet is off, the console writes "cash" as "points" and the Status page says so, and the backend credits points (cashMode() in firebase/functions/src/wallet/cash.ts).
• It applies to the four offerwall and survey providers (AdGem, Lootably, BitLabs, CPX Research), including the playtime offers inside their walls. Partner offers from console → Offers always credit points.
• The mode is the same for all users: wallet and economy.offerwallRewardMode can never be A/B-tested (experiments on them are ignored).
• Switching back to points affects new conversions only. Cash already in wallets stays there and stays payable.

Setup of the providers themselves (ids, wall URLs, secrets, postback URLs) is unchanged: Offerwalls and surveys.

02The user share

From cashAmounts() in firebase/functions/src/wallet/cash.ts and userShareCents() in money.ts:

1. Provider payout in USDThe payout the provider reports in its postback (in cents). If the postback carries no USD payout, nothing is credited (outcome zero). The provider's own points amount is never used for cash.
2. Into the wallet currencyFor USD nothing changes. For another currency: × wallet.usdRate, rounded half down.
3. The user's sharefloor(provider payout × share / 100), where share is wallet.vipUserSharePercent for an active VIP, else wallet.userSharePercent. The rest is your margin.

Example from the console help: the provider pays 1.00 USD, the share is 50 % → 0.50 goes to the user's wallet. The VIP or booster points multiplier is never applied to cash.

03The hold (pending cash)

Every cash credit from an offer, a survey or a referral commission starts as pending for wallet.holdDays days (default 14, allowed 0 to 365). The hourly job releaseWallet then moves it to available. With 0 days it becomes available on the next hourly run.

Pick the hold to match the reversal window of your providers. A reversal inside the hold removes pending cash cleanly; a reversal after release takes it from the available balance (below).

04Holding big credits for review

Console → Anti-fraud → Hold cash offerwall credits above (cents) (fraud.offerwallHoldOverCents, default 2000 = 20.00 in a 2-decimal currency, 0 = off). A cash credit above it, and every cash credit of a flagged user, waits in console → Review queue with its cash amount instead of being credited. Approving it lets the backend credit the wallet once; rejecting credits nothing. The points-mode threshold (fraud.offerwallHoldOverPoints) still applies in points mode only. See Review queue workflow.

05Reversals and chargebacks

When a provider reverses a conversion (Lootably status=0, BitLabs RECONCILIATION, CPX status=2; AdGem documents none, details), the backend reverses the cash credit and the referral commission it paid on it (reverseCash()):

• If the credit is still pending, it is taken from pending and the entry becomes void; it is never released.
• If it was already released (or paid out), it is taken from the available balance, which may go negative.
• With a negative available balance the user cannot request payouts (reason negative_balance, in the app: "Your balance is negative because a partner reversed an offer. New earnings settle it first."). New earnings settle it first.
• The reversal also writes a negative revenue event, so the Business page margin stays honest.

Watch for users with many reversals: a payout request from a user whose reversals exceed 20 % of their conversions in the last 30 days is flagged reversal_rate (Fraud signals).

06Referral commission

When an invited user receives a cash credit, their inviter gets a commission as pending cash with the same hold (creditCash()):

• Amount: floor(user's credit × percent / 100), on top of the user's credit. You pay it from your margin; it does not reduce the invitee's share.
• Level 1 only: the direct inviter. The second referral level of 3.1 (economy.referralTier2Points) pays points, never cash.
• No commission to a banned inviter, and none after the window.
• Reversed together with the credit it came from.
• The default of 10 pays nothing while the wallet is off. Set it to 0 if you do not want to pay commissions.

Points for invites (economy.referralInviterPoints, economy.referralInviteePoints and the second level) are separate and unchanged: Rewards economy.

07Grants: cash you give by hand

Console → Wallets → a user → Grant cash: an amount and a reason (for example "contest prize October"). The backend writes a grant entry that is available at once, with your e-mail as the actor, and the console audits it. Use it for contest prizes or goodwill payments; it is paid from your own money.

08Before you switch to cash

• Your providers allow cash rewards to users in your app and countries (read each publisher agreement)
• Each provider reports a USD payout in its postback (otherwise cash conversions credit nothing)
• Hold days match your providers' reversal window
• User share, VIP share and referral commission leave you a margin after payout fees (Example calculator)
• Payout methods and limits are set and your payout accounts are funded (Payout methods)
• Terms, privacy policy and the wallet notice are updated (Your legal duties)