#Installation

#Quick start

#1. «Poool», WTF?

Poool is a dynamic Paywall. It gives the power back to editors so they can control how readers access their content. This is done through simple compensation choices that are customized to a reader based on their engagement. Clever, eh?

#2. Making sure Poool ends up in the right place

Installing Poool couldn't be easier! Simply add a tag inside your page. Do make sure though that your tag is in the right place! We want to make sure your paywall performance is at its best so remember to call Poool with the highest priority on the page.

#3. Tag the pages and set up the paywall

We made Poool's tag so that it should be integrated in every page, just like a classic Analytics tag.
    1. Add the tag to all pages, anywhere within the code, replacing values where necessary:
And as if by magic, your data should now be logged!
    1. Tell Poool where your post content is (using data-poool attribute)
    1. Add the Poool widget container outside the content of your article:
Sorted! Poool's widget should show up!

#Install in AMP

AMP is an open-source initiative created by Google aiming to make the web better for all.
Poool's Paywall is fully compatible with AMP. See amp-access-poool extension documentation.
In order to show your usual Poool Paywall inside AMP, import scripts for both amp-access & amp-access-poool extensions within your page:
Add your amp-access configuration for Poool:
And organize your sections containing separately your article's excerpt, the complete article contet and the paywall:
And voilà, your Poool Paywall should be displayed correctly inside AMP! See an example integration.

#Compatibility

ChromeFirefoxEdgeSafariSafari iOSChrome AndroidXCodeiOSVueAndroid SDK
ChromeFirefoxEdgeSafariSafari iOSChrome AndroidXCodeiOSVueAndroid SDK
37+34+18+11+iOS 11+Android 37+11.0+13.0+3.0.0+21+

#Frequently Asked Questions


#I want to disable Poool for my paying subscribers, how can I do this?

For security reasons, Poool's tag won't take responsibility by disabling the paywall for an article it didn't unlocked directly.
Hence, you should disable the paywall manually if needed - e.g. for a paying subscriber.
  • If you don't want to cut your post content, simply remove the data-poool & data-poool-mode attributes from your page
  • If you don't want to show the paywall, remove the <div id="poool-widget"></div> element from your page

#I'm installing Poool on a one-page app (Angular, React, Vue, ...), will this be compatible?

Poool is compatible with all the recents javascript frameworks. Our own demo for example is a React app!
However, it's not possible to cut the content of an article if dynamic elements from frameworks (React/Vue components, Angular directives, ...) are found inside article content. We therefore advise one-page applications to use our custom masking mode and do their own logic to hide their content.
Implementation examples are available on our Github:
In addition to that, to prevent any information to be passed from one page to another (only for one-page apps), it is often necessary to do a call to flush before a new navigation event (ex: componentWillUnmount for React, ngOnDestroy for Angular, beforeRouteLeave for Vue, ...) to reset some configuration values back to their original value:

#My user login flow is not on a new page, what should I do?

Thanks to onLoginClick & onSubscribeClick events, you don't have to provide a login or a subsription URL to the paywall. You can also disable the default behavior of the login & subscribe buttons:

#Why doesn't Poool's paywall detect data-poool & data-poool-mode attributes in the page while they are present?

In some very rare cases, the DOM of the page takes longer to load than the paywall script itself. Therefore, as the data-poool and data-poool-mode attributes aren't yet available when the paywall script loads, the default configuration will be used.
To compensate for this eventuality, you may need to use the wait_for_dom_load configuration option which will wait for the DOMContentLoaded event of the browser to be fired before executing the paywall:

#Poool's paywall is not loading fast enough, or not loading at all, what should I do?

We take pride in using the necessary resources to ensure that the operation of our Paywall isn't interrupted.
Nevertheless, we have put in place some procedures just in case:
  • If the paywall takes too long to load (more than 10s), we stop all pending requests from the paywall and display a default hard paywall.
  • If the paywall encounters an unexpected error, we directly trigger the onError event so that you can display a fallback paywall.
In both cases, if Poool's paywall cannot load its custom appearance (and it is not in the reader's browser cache yet) and its various configuration options, you can configure them directly with the paywall's Javascript API:

#Poool does not load when scripts are not supported or when they are disabled. What can I do?

In order to make our solution available in any case (for example when Javascript is disabled on the user's browser), we have implemented a system that lets you to display Poool's paywall the same way it shows when your reader has not allowed cookies on your website (with default settings).
Via the simple implementation of an iframe tag, you can display a restrictive widget (required subscription) that will use the appearance settings and the messages that have been saved on your Dashboard. Please note that tracking features will be disabled exactly like when the user refuses cookies.

#When validating the fields of the Form widget, I need to make verifications and/or process data on the server side. What can I do?

To fulfill this need, we made event sending asynchronous. In other words, it is now possible to implement a promise logic within the configuration of a Poool event.
Once put in place, we wait for the promise to be resolved then the result is sent.

#When sending a form with a credit card field, I want to create a payment on my reader's credit card with Stripe, what should I do?

For security reasons, we have chosen not to store the identifiers necessary for server-side payment with Stripe, to leave you fully in control of the security of your platform, from start to finish.
To create a charge on the server side, you just need to pass your Stripe public key on the front side, and make a call to your APIs with the credit card information retrieved from the onFormSubmit event.
For the server part, Stripe has an SDK for practically all the languages vailable today. Just browse the Stripe documentation to find the version that matches your language.
A concrete example with the Stripe PHP SDK: