RevenueCat: how to run a custom paywall UI alongside RevenueCat Paywalls (without splitting purchase logic)

Original article (source): RevenueCat Engineering - “Running custom built paywalls alongside RevenueCat Paywalls” (February 10, 2026)

• https://www.revenuecat.com/blog/engineering/running-custom-paywalls-alongside-revenuecat-paywalls/

The problem this solves

If you’ve ever shipped a custom paywall, you know the pain:

• The UI becomes tightly coupled to pricing logic.
• A/B tests turn into app releases.
• Offer eligibility is inconsistent across screens.
• Entitlement edge cases multiply.

RevenueCat’s point is simple: you can mix paywall UIs without splitting the purchase and entitlement system.

The “hybrid paywall” pattern

You keep one monetization backbone:

• Products + prices are fetched from RevenueCat Offerings.
• Purchases are always initiated via the RevenueCat SDK.
• Entitlements always come from RevenueCat CustomerInfo.

But you can choose between two presentation layers:

• RevenueCat Paywalls (dashboard-managed templates)
• Your own custom paywall UI (fully bespoke)

So the app controls what you show, while RevenueCat controls what’s for sale and what unlocks.

How you decide which UI to show

RevenueCat calls out two practical levers.

1) Target by placement

Define explicit “paywall moments” in your app journey:

• onboarding_end
• feature_gate
• sale_offer

Then request the current Offering for that placement. Different placements can serve different Offerings and different paywalls.

2) Target by offering metadata

Attach a small JSON flag to an Offering in the RevenueCat dashboard (example):

{ "custom_paywall": true }

Then in-app, read offering.metadata and branch:

• custom_paywall = true → render your custom UI
• otherwise → render RevenueCat Paywalls

The key detail: treat metadata as optional, so the paywall decision never hard-crashes your monetization flow.

Why this matters for growth teams (not just engineers)

1. Faster iteration without “pricing drift”. When the price and entitlement source-of-truth stays centralized, you avoid shipping a beautiful new paywall that accidentally sells the wrong thing.

2. Cleaner experimentation. You can test:

• custom UI vs template UI
• different placements
• different offer stacks

…while keeping the downstream subscription state consistent.

3. More honest personalization. Targeted offers become real when the paywall and product configuration are aligned, not stitched together across multiple screens.

Tiny win

Pick one paywall moment (like feature_gate) and add a single Offering metadata flag that controls UI choice (custom vs template). Then verify, end-to-end, that:

• the paywall is always rendering products from Offerings
• every purchase is initiated in the RevenueCat SDK
• entitlement checks only read from CustomerInfo

Read the original: https://www.revenuecat.com/blog/engineering/running-custom-paywalls-alongside-revenuecat-paywalls/