Availability
This feature is available as a beta.
Tulo Paywall¶
Target Audience: Users, Stakeholders, Developers
Introduction¶
Tulo Paywalls in Payway offer our customers an easy way of setting up a dynamic paywall that presents the end user with an offer best suited for them.
This means you no longer have to maintain a complex paywall based on integrations sprouting left and right, fetching accounts and products, performing order validation and keeping track of providers and their implementations and all the different contexts the end user can find themselves in.
Example of Tulo Paywall
Tulo Paywall¶
A Tulo Paywall is a combination of a template and an offer. The template contains the presentation logic while the offer contains the product details.
The paywall's job is to:
- Present your users with templated offers tailored for each site.
- Evaluate the best offer for that user based on history, order validation, configuration, and more.
- Measure the performance on each paywall so you can see what works best for you.
Offer¶
An offer contains information about what product will be offered to the customer. If it's a package, campaign, or a campaign staircase and to what price?
Types¶
The type defines how the Tulo Paywall will try and resolve what kind of offer to present.
If the user is not eligible for the configured offer type the paywall will automatically evaluate the best offer available to the user.
Area of sale¶
Keeps track of what area of sale will be used. Basically, where will the user perform his or her purchase.
A couple of examples of an area of sales would be:
- Payway purchase flow or PPF (Legacy)
- Tulo Shop Checkout
- Klarna Payments Checkout
Offer evaluation¶
The Tulo Paywall will always try and work out the best offer for the user, logged in or anonymous.
For anonymous users, there's of course no need to evaluate any rule sets. The configured offer will hence be shown.
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 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 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 evaluating 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 to 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 to 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 to 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 to 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.
Template¶
A template defines how the layout and presentation for an offer are presented on the Tulo Paywall. You have the option to simply use our default template right out of the box. Or you can tweak your template yourself to achieve those custom cases you need.
Read more here on how you edit templates in PAP.
Types¶
Keeps track of what type of template that should be rendered.