xorkeesign subscriptions and units
xorkeesign subscription is measured in units. One unit stands for one month use of xorkeesign for one user. The user may sign in the browser, use the xorkeesign server to store and sign documents, use the xorkee wand to sign documents and invoices on the desktop, use the various browser extensions like xorkeesign G2C and email signing etc., Only things that cannot be done within this basic subscription is creating an Entity or an application to make calls to the xorkeesign API. Even there, the use is measured in units but the user will have to spend additional units over and above his basic subscription.
In this guide xorkeesign subscribers are generally called ‘users’. If a subscriber is also part of a sub-group in xorkeesign like an entity or an application, he is termed as a member within that context. Similarly members who are added to a subscription pool are referred to as beneficiaries within the context of the pool. Thus all members are users but no all users are members.
Purchase of units
Units can be purchased directly from the xorkeestore interface. The unit price is a constant value that is multiplied by the number of units the user purchases to arrive at the price payable. Any applicable taxes shall of course have to be added. The units purchased in xorkeestore shall generally remain to the buyer's credit in the store itself. For consumption, xorkeesign will automatically pull the necessary units from this stock in xorkeestore.
The user can also transfer the units from himself to another xorkee user in xorkeestore. Such transfers can take place as many times as desired. However, units once transferred to xorkeesign cannot be transferred back to xorkee store.
Purchases in xorkeesign
The unit purchase interface is also available in xorkeesign itself. The units will also be held in xorkeesign and can be transferred but only once. Thus if A purchases 100 units in his xorkeesign interface and transfers 10 of those units to B’s account in xorkeesign, B cannot further transfer them to anyone. He can use it only for his own personal consumption in xorkeesign. The 90 units remaining with A can be transferred anytime at A’s will and they are called transferable units. The 10 units received by B are called non-transferable units. This distinction is important because some features in xorkeesign such as subscription pooling can only be accessed using transferable units.
Users holding units in xorkeestore can also ‘pull’ those units from the store to their xorkeesign account. These units will be treated as if the user has purchased them in the xorkeesign interface. They can use them or transfer them to other users but the receiving users cannot further transfer them.
These restrictions are meant to facilitate bulk purchases in organizations and distribution to other users in the organization who in turn cannot misuse it by transferring it to someone else.
Subscription pools
Users with at least ten transferable units to their credit in xorkeesign can create a special device called a subscription pool. The pool acts as a simple device for distribution of units from a centralized procurement point such as the purchase manager or HR manager in organizations.
Members in the pool context are also called beneficiaries.
The creating user can add members to the pool one after the other or by importing a list as a CSV file. Every pool member, when he runs out of units and his basic subscription is due, will automatically receive one unit from the pool that will be used for his basic subscription. Thus the members of the pool need not even be aware of the subscription mechanism and can simply use xorkeesign. This is extremely helpful to organizations who seek to centralize subscription management for their employees and at the same time avail the discount benefits of volume purchases.
Pool members can also draw from the pool for any API or Entity they (the pool member) are administering provided the Pool owner has specified the ‘type’ of this member as ‘Enhanced’. The type of a member can be set or changed by the pool owner at any time. When a member who already administers an Application or Entity is added to a pool, his default type will also be set as ‘Enhanced’ by xorkeesign.
Another significant benefit of pooled subscription is where a professional service provider bundles a xorkeesign subscription as part of his or her service. Thus, accounting service providers can include a xorkeesign subscription as part of the taxation and other filing services they provide to their clients. This again offers the economies of volume to service providers and a minimum of bother for the actual users.
In addition to directly adding members to a pool, the pool owners also can auto-import users on the basis of their membership in an API or entity or even a distinguishable service offered through a browser extension.
Consumption of units
Basic subscription
As already stated, the basic usage of xorkeesign consumes one unit per month. Here the month is counted from the date the user starts actually signing using xorkeesign. (Logging into xorkeesign will also count as a signature). The next unit shall be due on the same date the next calendar month but will actually be consumed only when the user does his signature after the due date. Thus if he buys the subscription on 15 Jan 2024, his next subscription shall be due on 15 Feb 2024. But if he does not use xorkeesign on 15 Feb 2024 but resumes signing only on 20 Feb 2024, his subscription shall be counted from 20 Feb 2024 and his next due shall arise only on 20 Mar 2024. The user does not pay for unused days after expiry of subscription. If the subscription due falls on a non-existent date like say Feb 30th or April 31st, the day will be shifted to the 1st of next month.
API subscription
The user’s basic subscription shall not cover creation of any API consuming application in xorkeesign. In addition to his basic subscription, xorkeesign will also consume one additional unit for every 20 members or part thereof added into the application. Here, regardless of whether the users carried out signatures one unit will be debited for every 20 members (or part thereof) per calendar month.
For API subscription a Calendar month is taken as the temporal unit. However, smaller fragments of a month (less than 10 days) in the beginning shall not be counted. Thus, an application (API) created on 19th of January shall be due for renewal on 1st of February whereas an application created on 20th of January shall be renewable on 1st of March only. This is applicable only to the first month after application creation by the user. All the subsequent months, regardless of actual usage, the units for the application shall be debited on the first of every month. If there were inadequate units in application owner's credit on the first of a month, the application will stop working and return error for all API calls. If units were credited to the user’s account on any date after the due date, the application will be automatically reactivated.
API members’ subscription
The consumption mentioned for the API users is in addition to the members’ individual basic subscription. Thus every member added to an API application should have his own basic subscription properly renewed.
Guest signatures
The exception to this is when the application (API) treats a member as a guest. Such guest members need not be subscribed to xorkeesign. The application owner should additionally provide one unit for every 100 such guest signatures or part thereof in every calendar month.
Applications with zero members
Even if an application (API) has no members, a minimum subscription of one unit shall be debited on every due date. This one unit will automatically cover up to 20 members or 100 guest signatures.
Entity subscription
For creating an entity in xorkeesign, the entity owners shall be charged additional units on the basis of members added to the entity. The charges here shall be one unit per 50 members with a minimum of one unit per month. The dates as applicable to the API shall also apply to entities.
No guest users can be added to an Entity.
