This page covers the main monetization flow, including download earnings, premium-sale earnings, referral earnings, hold windows, fraud review, and withdrawals.

• enable rewards
• select supported models
• set PPD, PPS, Hybrid, and referral percentages
• configure payout methods
• set hold windows and retention windows
• review withdrawal thresholds and supported methods

• PPD pays the uploader for qualifying downloads.
• PPS pays the uploader for attributed premium purchases.
• Hybrid pays both, using the configured mixed percentages instead of the full standalone PPD and PPS values.
• Referral is separate from those models and applies to referred-user earnings according to the site referral rate.

Operators should treat those as distinct controls. If the numbers look wrong on the affiliate page or rewards screens, check the Monetization tab first.

Fyuhls now uses the public user referral flow for account-side referrals and no longer relies on legacy numeric internal referral IDs in the public ?ref= path.

Important operating points:

• referral earnings can be held before clearing
• the default affiliate hold window is 5 days unless you change it
• refunded or denied premium transactions should cancel or reverse the related downstream earnings
• referral reporting should be read as an earning-oriented metric, not just a raw signup count

When rewards are enabled, cron becomes much more important because it handles:

• queue flushing
• history rollups
• fraud score refreshes
• held earning clearance
• old fraud-event cleanup

If held rewards or referral balances are not clearing on time, check the cron page before assuming the reward engine itself is broken.

• review pending withdrawals regularly
• inspect uploader context before approving suspicious requests
• cross-check rewards fraud when the payout pattern feels off
• do not approve withdrawals blind when large held balances just cleared
• verify whether the user balance contains download earnings, premium-sale earnings, referral earnings, or a mix of all three

Users can now store a default payout method and payout details from:

• /settings

Those saved defaults are then used to prefill the withdrawal request flow on:

• /rewards

That means operators should expect payout requests to more often arrive with a consistent saved destination instead of being typed fresh every time.

If a user says the payout modal is blank when they already saved a default method, check:

• their saved account settings
• the selected payout method
• whether the rewards page is loading their current saved payout details correctly

• Rewards Fraud
• Stripe and PayPal Payments
• Config Hub Reference