Securing Paid Content

there are two main patterns to handle paid content paywalls and fallbacks some projects use one of the two; some projects use both fallback a fallback may be configured on any overview page it prevents the article from being opened if the user is not entitled to read it instead of opening the content, it will execute any fallback action configured mostly, this is the login or purchase for creating a flow that will allow users to log in and then open the content, see docid\ crtyyrilosantdxmgad7v given users may directly access any url, there might be a need to additionally set up a paywall, see below paywall purple experience supports the creation of paywalls as on a per customer basis, different systems and third party systems are used starting in pxp 5 0, the default behavior for any content api is to only provide the previewhtml for any content that's the content defined to be free in any case, despite any login or entitlement status we define paywall as the ui that will block a user from consuming content he is not entitled to (for details on configuring entitlements, see docid\ jdbb46p14fcu2slttccrv ) often, specific content is marked as paid content, while other content from the same application is available without a subscription paywall behaviour any content that is marked as paid will be initially loaded with a paywall at runtime, we evaluate the entitlement of the user, and based on the result, remove the paywall and display the actual content with that, we provide the highest safety for the content while allowing for efficient caching policies this approach may lead to a flickering behavior when the paywall is removed, depending on internet connectivity or the influence of browser plugins on very slow connections, users may see the paywall for a longer period of time until the actual content is available