Using AMP (Accelerated Mobile Pages)

The overarching goal of AMP is to get pages to load faster on mobile devices. Part of the way that’s accomplished is by disallowing third-party scripts that might delay rendering. This means that the Wallit JavaScript Library can’t be used.

Wallit supports the amp-access extension for AMP. This allows you to create valid AMP documents that enforce access control and paywall functionality through Wallit.

Implementing amp-access

Before integrating Wallit, be sure you’ve followed the basic guidelines for creating a valid AMP page.

Basic Setup

To use Wallit’s paywall, add a reference to the amp-access extension and, depending on your requirements, the amp-mustache extension. Next, define the amp-access settings. Use your Access API key in the URLs - the example below has an API key of b865156f-9e0d-48b6-a2a0-097456f689ec. Everything else can be copied verbatim from the example below - AMP will automatically populate the variables like READER_ID when it processes the page.

<script async custom-element="amp-access" src=""></script>
<script async custom-template="amp-mustache" src=""></script>

<script id="amp-access" type="application/json">
	"authorization": "",
	"pingback": "",
	"login": {
		"log-in": "",
		"log-out": ""
	"authorizationFallbackResponse": {
		"error": true,
		"accessReason": "Deny",
		"isAnonymousUser": true

Defining Protected Content

Use the amp-access attribute to control which parts of the page are publicly accessible and which are protected. The main thing to check if the accessReason value. If it’s set to Deny, the user doesn’t have access to the resource.

Here’s an example:

<div amp-access="accessReason = 'Deny'" amp-access-hide>
	You do not have access to this content.
<div amp-access="NOT (accessReason = 'Deny')" amp-access-hide>
	This is protected content.

To send the user to the paywall, call tap:amp-access.login-log-in. To log a user out, call tap:amp-access.login-log-out. For instance:

<div amp-access="accessReason = 'Deny'" amp-access-hide>
  <p>To read more, you must purchase this page.</p>
  <button on="tap:amp-access.login-log-in">Purchase</button>

To display a “Log Out” button if the user is authenticated:

<div amp-access="NOT isAnonymousUser" amp-access-hide>
  <template amp-access-template type="amp-mustache">
	<button on="tap:amp-access.login-log-out">Log Out</button>


If you use metered pricing, you can display information about the user’s meter by accessing the Quota object. For instance:

<section amp-access="quota">
  <template amp-access-template type="amp-mustache">
	You are reading page {{quota.hitCount}} out of {{quota.allowedHits}}.

External Keys and Canonical URLs

Wallit’s access control mechanisms assume every resource has an API key and a resource/external key associated with it. This combination of keys uniquely identifies a resource, which allows Wallit to determine access rights.

With AMP, there’s no way to specify an external key from the client-side (as there is with Wallit’s JavaScript Library). Instead, Wallit uses the canonical URL of the document (which an AMP document is required to have) as an identifier, looking for an existing resource with that same URL. If there is more than one resource defined with that URL, Wallit will pick the oldest resource. Note that the canonical URL must exactly match the URL stored for a resource – so both should be absolute URLs.

Wallit’s dynamic resource creation relies on using a script tag to convey detailed metadata, which isn’t allowed on AMP pages. When dynamic resource creation occurs for an AMP page, the canonical page will be spidered, if provided. This means that additional metadata can be provided on the canonical page. It also means that the canonical page and the AMP page will be treated as a single resource.

Unsupported Wallit Features When Using AMP

Some Wallit features are not compatible with or are ignored on AMP pages:

Embedded paywall

Embedded wallet

Embedded confirmation

Ad blocker detection, ad blocker metering, and ad blocker pricing