Single Offer and Multiple Offers Licensing Models

Here is the typical workflow for the creation and the installation of a third-party license for an extension using the single offer or multiple offers licensing models in Plesk:

image 78960

Step by step description of the above diagram:

  1. A customer comes to Plesk Online Store and orders a new third-party license.

  2. Plesk Online Store takes care of payment but delegates creation of the new license to KA.

  3. KA calls the ISV endpoint with License Creation/Renewal/Upgrade Request (the PURCHASE action) to request a new license, and, after a successful response, stores the body of the license in the KA database.

  4. Finally, the customer gets an activation code for a newly created license.

  5. The customer goes to Tools & Settings > License Management in the Plesk user interface, goes to the Additional License Keys tab, clicks Install Key, and then enters the activation code:

    image 77941

  6. Plesk connects to KA to retrieve the license body by the entered activation code.

  7. When the license is successfully installed, Plesk extension can retrieve it using Plesk SDK.

Pay-as-you-go Licensing Model

The pay-as-you-go (PAYG) licensing model allows for billing based on resource consumption. To facilitate that, the vendor’s system must regularly send telemetry data about resource usage for active licenses to Key Administrator. Key Administrator then calculates the peak resource usage for each day. At the end of the month, the client is billed for the resources they used. The PAYG licensing model supports both hosted solutions and software as a service solutions.

To enable PAYG billing, the following requirements must be met:

  • The logic for collecting resource usage data must be implemented in the vendor’s system.
  • Resource usage data must be collected from running application instances.
  • Telemetry containing resource usage data must be sent twice per day to Key Administrator.

Integrating a software as a service solution with PAYG

Here is the typical workflow for the creation and the installation of a third-party license for a software as a service solution using the PAYG licensing model in Plesk:

image payg workflow saas

A step-by-step description of the above diagram:

  1. A partner submits a request to Key Administrator for the creation of an inactive license.
  2. Key Administrator provides an activation link to the partner.
  3. The partner is redirected to the vendor’s system.
  4. The vendor’s system generates a unique vendor token associated with the order.
  5. The vendor activates the license in Key Administrator using the unique vendor token.
  6. Key administrator submits a request to the vendor’s system for the creation of a record for the provided unique vendor token.

Prerequisites and service level requirements

To use the PAYG licensing model, you need to set up the reporting of telemetry containing resource usage data to Key Administrator using the PAYG telemetry API.

Also, pay attention to the following requirements:

  • Telemetry data must be sent twice a day. The resource usage data must be accurate and complete.
  • Any issues with sending telemetry data must be fixed within 12 hours of the issue occurring. Failure to send telemetry data twice in a row may result in payment due to you being calculated incorrectly.

The Key Administrator system receiving telemetry data commits to maintaining 99% availability.

Individual Offers Licensing Model

Here is the typical workflow for the creation and delivery of a third-party license for an extension using the individual offers licensing model in Plesk:

image 78961

A step-by-step description of the above diagram:

  1. A customer (Plesk administrator or a Plesk end user) logs in to Plesk. The customer selects a domain or a website and chooses the desired product among the products offered by the extension.
  2. The extension generates an unique token that will be associated with the order and will be used through the entire workflow.
  3. The customer is forwarded to Plesk Online Store to complete his or her order. The token is passed as one of the query string parameters.
  4. The Online Store processes the payment, notifies KA about the purchase, and passes the token to KA.
  5. KA calls the ISV endpoint with a License Creation/Renewal/Upgrade Request (the PURCHASE action) passing the token inside the ACTIVATION_DATA parameter.
  6. The extension checks the status of the order on the ISV side using the token. When the order is ready for fulfillment, the extension executes it (e.g. delivers the product to the selected domain/website).
  7. The protocol used to check the status of the order is not specified and can vary from extension to extension.