Tulo Paywall - Customer eligibility¶

Target Audience: Users, Stakeholders, Developers

Offer evaluation¶

The Tulo Paywall will always try to work out the best offer for the user, logged in or anonymous.

Package¶

We will evaluate if the user is eligible to purchase the configured package, according to the following ruleset:

Does the user already have the package at hand?
Can the user buy the package now, but with a future start date?

If the user is not eligible for the package, an error will be shown.

Campaign¶

We will evaluate if the user is eligible to purchase the configured campaign, according to the following ruleset:

Does the user already have the campaign at hand?
Does the user already have the campaign's underlying package?
Can the user buy the campaign now, but with a future start date?
Is the user allowed to purchase according to your configured campaign purchase rules?
Are users allowed to repurchase campaigns? This is an optional feature that is disabled by default but can be enabled by contacting our support.

If the user is not eligible to purchase the campaign we will evaluate the underlying package with the corresponding rule set.

Campaign staircase¶

We will evaluate what campaign the user is eligible for in the configured campaign staircase, by assessing each campaign in the staircase according to the following ruleset:

Does the user already have the campaign at hand?
Does the user already have the underlying package of the campaign?
Can the user buy the campaign now, but with a future start date?
Is the user allowed to purchase according to your configured campaign purchase rules?
Are users allowed to repurchase campaigns? This is an optional feature that is disabled by default but can be enabled by contacting our support.

If the user is not eligible for any of the campaigns in the staircase we will evaluate the package the campaign staircase is configured for instead.

Price evaluation¶

Depending on the offer type the price is evaluated a bit differently. Note that each payment period must be enabled to be considered/evaluated.

Priority	Evaluation
1	Return the configured Tulo Paywall offer period
2	Find the shortest period, using the same payment option from the configured period on the offer
3	Find the shortest period, according to the sorted payment options that you have configured
4	Raise an error since no price can be given

Examples¶

To give you an idea of what the table above means, we have provided some examples below. If you find that your scenario does not match any of the examples, feel free to consult our support.

Scenario 1

My Tulo Paywall is based on a package offer. The customer, interested in the Paywall, does not currently have the package.

This scenario would evaluate the configured offer period being presented to the customer.

Scenario 2

My Tulo Paywall is based on a package offer. The customer, interested in the Paywall, currently has the package.

This scenario would evaluate an error being shown to the customer.

Scenario 3

My Tulo Paywall is based on a campaign offer. The customer, interested in the Paywall, currently has the campaign, but not the underlying package. The customer has chosen to pay via Invoice.

This scenario would evaluate the shortest invoice period on the underlying package being presented to the customer.

Scenario 4

My Tulo Paywall is based on a campaign offer. The customer, interested in the Paywall, currently has the campaign, but not the underlying package. The customer has chosen to pay via Invoice, but the underlying package is missing an invoice period completely.

This scenario would evaluate the payment option on the underlying package, that is of the highest priority according to your sorted payment options, to be presented to the customer.

Customer is not eligible for purchase¶

There are several cases where a customer can be refused the configured paywall offer.

These reasons can be but are not restricted to:

Campaign already purchased. The customer already has access to the package the campaign is based on.
Specific campaign purchase rules that exclude purchase.
Order validation: too old, too young, etc.
Anonymous user performing a Klarna Payments Checkout purchase.
Paywall presented to user that already has access.
And so forth...

In the best-case scenario, the paywall should of course not be shown to a customer who already has the access being offered. But there are cases where this cannot be avoided and we need to communicate to the customer what the next step is.

How can offer refusals be handled?¶

There are a couple of ways to handle refusals in the Tulo Paywall. The most common ones are handled automatically by the paywall. But you are also free to customize.

Implement your onError callback.¶

If an error occurs upon rendering the Tulo Paywall, an onError function will be triggered. By default, this means that an error will be shown to the end-user, and you will receive debug information (granted the debug flag is set to true) in the browser console. If you would like to override this behavior, you can simply define an onError function when initializing the paywall.

<script type="text/javascript">
    new TuloPaywall().Init({
        ....
        .......
        debug: true,
        onError: function(error) {
          //custom error logic here
        }
        ....
        .......
    });
</script>

Customize Error template¶

Some form of paywalls support a separate error template. E.g. Klarna Payments Checkout. The template contains by default a set of predefined error resources that can be overridden from PAP. For most cases, this is enough, but if you wish to customize this part you can extend the template logic using the [RESPONSE_PURCHASE_RESULT] variable.

<div class="paywall__error-container">
  <h2 class="paywall__error-title fs-vh-24">[ERROR_TITLE]</h2>
  <p class="paywall__error-text fs-vh-14">[ERROR_MESSAGE]</p>
  <p class="paywall__error-text fs-vh-14">[ERROR_RESOLUTION]</p>

  <a href="[ERROR_BUTTON_LINK]">
    <button class="paywall__error-button" id="paywall__error-button" type="button">[ERROR_BUTTON_TEXT]</button>
  </a>
</div>
<script type="text/payway-paywall-js">
  let response = [RESPONSE_PURCHASE_RESULT];
  console.log(response);
</script>

Based on the purchase_status object you can see what the reason was for the refusal. And if possible we will present a resolution in resolve. In this case, we urge you to login_user so the paywall can best evaluate the offer.

[RESPONSE_PURCHASE_RESULT] payload example

{
  "purchase_status": {
    "code": "failed",
    "reason": "campaign_already_purchased",
    "resolve": "login_user",
    "display_alternative_offer": false
  },
  "account": {
    "id": "account_id",
    "status": "completed",
    "registered_from_purchase": false
  },
  "order": {
    "order_id": "ADEPRIMOEN-1234",
    "klarna_order_id": "xxxxx",
    "receipt_id": null,
    "redirect_url": null
  },
  "offering": {
    "initial": {
      "product": {
        "id": "product_id_1",
        "name": "Paywall offer",
        "code": "paywall_offer"
      },
      "period": {
        "id": "period_id"
      }
    },
    "alternative": {
      "product": {
        "id": "product_id_2",
        "name": "Alternative offer",
        "code": "alternative_offer",
        "type": "campaign_staircase"
      },
      "period": {
        "id": "period_id_2"
      }
    }
  }
}

Customize Alternative Offer template¶

Some form of paywalls support a separate alternative offer template. E.g. Klarna Payments Checkout. The template contains by default a set of predefined alternative offer resources that can be overridden from PAP.

This template will be shown whenever the customer was not eligible for the initial offer, but we have found them an alternate offer that they might be interested in. This includes, but is not limited to:

Campaign staircases, where the customer is no longer eligible for the first step in the staircase, but is eligible for the second.
Campaigns, where the customer is no longer eligible for the campaign itself, but is eligible for the underlying package.