Remix

Make your own version of MCash Rewards Landing

Edit the prompt below and generate a customized version in seconds.

Original by Abhishek Singh Rajawat Abhishek Singh Rajawat

Describe your app

Create a modern landing page.

Color scheme: Blue & White

Include: hero with CTA, social proof, features grid, how it works, testimonials, pricing tiers, FAQ accordion, CTA footer, and footer. Responsive with smooth scroll.

suii

# MCash — Production-Grade Reward Web Application

## Master Frontend + Backend Architecture Prompt

Build a highly professional, production-ready reward web application called **MCash**.

The application must be fully responsive and optimized for both **mobile phones and laptops/desktops**.

The visual language should be inspired by the premium, clean, modern feel of the **mRewards-style reward-app experience**, but the implementation, branding, components, layouts, assets, and code must be original and not copy proprietary UI assets or source code.

---

# 1. PRODUCT OBJECTIVE

MCash is a CPA-based rewards platform where users complete app-install campaigns and receive virtual rewards called **Coins**.

The entire user-facing application must use **Coins only**.

### Critical currency rule

The user interface must NEVER display:

* ₹
* INR
* $
* USD
* monetary currency symbols
* CPA payout amounts
* admin profit amounts in monetary currency

Users should only see:

> Coins

Internal backend calculations may use a base monetary value for accounting purposes, but that value must never be exposed in the normal user interface.

---

# 2. COIN ECONOMY

Use this fixed internal conversion:

**1000 Coins = 1 INR**

For every successfully verified CPA conversion:

**40% → User reward**

**60% → Admin net profit**

Example:

CPA network revenue:

`1 INR`

Internal accounting:

`60% Admin = 0.60 INR`

`40% User = 0.40 INR`

User reward:

`400 Coins`

Therefore:

> Every 1 INR of verified CPA revenue generates exactly 400 Coins for the user.

The backend must calculate rewards using integer-safe arithmetic / smallest monetary units to prevent floating-point errors.

Do not perform financial calculations using unsafe floating-point arithmetic.

---

# 3. REWARD LEDGER

Do NOT rely on simply modifying:

`users.coins`

Instead, create a proper transaction/ledger system.

Recommended structure:

### users

* id
* google_id
* email
* name
* profile_image
* wallet_balance
* status
* blocked_reason
* created_at
* updated_at

### wallet_transactions

* id
* user_id
* type
* coins
* reference_id
* status
* description
* created_at

Possible transaction types:

* CPA_REWARD
* WITHDRAWAL
* WITHDRAWAL_REVERSAL
* ADMIN_ADJUSTMENT

Every wallet change must create an immutable transaction record.

The current wallet balance can be maintained as a cached value, but the transaction ledger must remain the source of truth for auditing.

---

# 4. CPA POSTBACK ARCHITECTURE

Create a secure backend postback endpoint.

Example conceptual endpoint:

`POST /api/postback/mylead`

The endpoint must NOT trust arbitrary client-side requests.

The backend should:

1. Receive the CPA network postback.
2. Validate the campaign/conversion identifier.
3. Validate the user/click identifier.
4. Validate any available signature/token/security parameter.
5. Verify the conversion has not already been processed.
6. Store the raw postback event for auditing.
7. Determine the verified revenue internally.
8. Calculate the 40% user reward.
9. Calculate the 60% admin share.
10. Create the wallet transaction.
11. Update the user's wallet atomically.
12. Record the admin revenue transaction.
13. Return the appropriate success response to the CPA network.

---

# 5. DUPLICATE POSTBACK PROTECTION

CPA networks may retry postbacks.

Therefore, duplicate conversions must NEVER generate duplicate rewards.

Create a unique conversion/event identifier.

Example:

`external_conversion_id`

This must have a unique database constraint.

If the same conversion arrives again:

* do not credit the user again
* do not create another admin revenue record
* return an idempotent success response

The entire reward operation should happen inside a database transaction.

---

# 6. CAMPAIGN SYSTEM

The dashboard must contain **exactly 4 campaign spaces**.

At launch there may be no active campaigns.

Therefore, create four responsive campaign cards/placeholders.

Recommended layout:

Desktop:

`2 × 2`

Mobile:

`1 × 4`

Each card should contain:

* campaign image slot
* campaign title placeholder
* short description placeholder
* reward badge
* CTA button area

The reward badge should display exactly:

> Download & Get 400 Coins

Because there are currently no live campaign URLs, these should be **placeholder campaign slots**, not fake working campaigns.

Do not invent real advertiser names, app names, download URLs, or CPA links.

Create campaign data in the database so the admin can later activate a campaign without modifying frontend code.

---

# 7. CAMPAIGN DATABASE MODEL

Create:

### campaigns

* id
* title
* description
* image_url
* reward_coins
* tracking_url
* advertiser_name
* status
* sort_order
* created_at
* updated_at

Possible status:

* DRAFT
* ACTIVE
* PAUSED
* ARCHIVED

The frontend should only display campaigns where:

`status = ACTIVE`

If there are fewer than four active campaigns, display blank placeholder cards until exactly four campaign spaces are rendered.

---

# 8. CLICK / TRACKING SYSTEM

When a user clicks a campaign:

1. Verify the user is authenticated.
2. Verify the user's security status.
3. Check VPN/proxy status.
4. Generate a unique click ID.
5. Store the click.
6. Associate the click with:

* user
   * campaign
   * timestamp
   * IP risk information
   * device/session metadata where appropriate
7. Redirect the user to the CPA tracking URL.

Create:

### campaign_clicks

* id
* user_id
* campaign_id
* click_id
* external_tracking_id
* ip_hash
* user_agent_hash
* security_status
* created_at

Never put the reward-crediting logic directly into frontend JavaScript.

---

# 9. GOOGLE LOGIN ONLY

Authentication must exclusively use **Google OAuth**.

Do NOT implement:

* email/password signup
* email/password login
* password reset
* traditional account registration
* anonymous wallet access

Authentication flow:

`MCash → Google OAuth → Callback → Backend verification → Session → Dashboard`

Use secure OAuth implementation.

The backend must verify the Google identity token/server-side OAuth response.

Do not trust a user-provided email address.

The Google account identifier should be stored as the primary external identity:

`google_id`

Email can be stored as account information.

---

# 10. SESSION SECURITY

Use secure server-side sessions or properly implemented secure authentication tokens.

Security requirements:

* HttpOnly cookies
* Secure cookies in production
* SameSite protection
* CSRF protection where applicable
* session expiration
* session rotation
* logout invalidation
* server-side authorization checks

Never store sensitive authentication secrets in localStorage.

---

# 11. ANTI-VPN / ANTI-PROXY SECURITY LAYER

This is a CRITICAL feature.

MCash must prohibit VPN and proxy access because the platform depends on CPA traffic integrity.

Do NOT attempt to implement this purely in frontend JavaScript.

Implement server-side IP intelligence.

Every important request should pass through a security middleware.

Security middleware should evaluate:

* VPN detection
* proxy detection
* hosting/datacenter IP
* Tor exit node detection where available
* known anonymizer networks
* suspicious IP reputation
* abnormal request patterns
* rate limits
* automated/bot signals

Use a reputable IP intelligence/security provider through a backend integration.

Conceptual flow:

`Request`

↓

`Extract client IP`

↓

`IP Intelligence`

↓

`Risk evaluation`

↓

If suspicious:

`BLOCK`

Otherwise:

`CONTINUE`

---

# 12. FAIL-CLOSED SECURITY

For campaign completion/reward-sensitive endpoints:

If the security provider cannot verify the IP status, the system should NOT blindly reward the user.

Instead:

`SECURITY_CHECK_UNAVAILABLE`

→ temporarily deny campaign/reward action

→ log the event

→ allow the user to retry later

This prevents security failures from becoming reward bypasses.

---

# 13. VPN BLOCK MESSAGE

When VPN/proxy usage is detected, show a professional error screen.

Example UI message:

> Access Restricted
> VPN or Proxy usage is not permitted on MCash.
> Please disable your VPN or proxy connection and try again.

Do not expose internal detection-provider information.

Do not reveal security rules or scoring logic.

---

# 14. SECURITY EVENT LOGGING

Create:

### security_events

* id
* user_id
* event_type
* ip_hash
* risk_score
* provider
* action
* metadata
* created_at

Examples:

* VPN_DETECTED
* PROXY_DETECTED
* DATACENTER_IP
* TOR_DETECTED
* RATE_LIMIT
* SUSPICIOUS_ACTIVITY
* POSTBACK_REJECTED
* DUPLICATE_CONVERSION
* INVALID_SESSION

Admin should be able to review security events.

---

# 15. WITHDRAWAL SYSTEM

Minimum withdrawal threshold:

**4000 Coins**

The user cannot submit a withdrawal request below 4000 Coins.

The withdrawal interface should show:

> Minimum withdrawal: 4]

Free to use. No credit card required.