Billing Features
The Cloudesire platform provides a complete billing, invoicing and payments engine. This means that the marketplace can manage the entire selling process without external dependencies.
Before you read this section, please take a look to the glossaryto make sure you fully understand the terms that will be used in this section.
Overview
Each generated invoice contains the following elements:
- nominee: the customer name
- description: purchased application name
- one-off cost: product one-off setup cost if any
- license cost: application recurrent licensing cost
- pay-per-use application metrics: costs that vary depending on real usage of the application
- extra-resources: costs for prepaid resources
In the following screenshots, you can see some examples of invoices issued by Cloudesire:
Billing principles
These are the main billing principles:
- product licensing costs: at the beginning of each billing period (every 30 days) an invoice containing the application licensing costs and the IaaS costs is issued in advance to the customer. The one-off cost is charged only in the first billing period
- extra resources: if prepaid extra resources are defined, they are added into the same invoice of the licensing costs. If pay-as-you-go, at the end of the billing period, an invoice containing the pay-per-use costs is issued to the customer
- trial and sandbox orders: if an cloud application is offered in trial mode, cloud costs will be charged to the vendor, in the same report where earnings are calculated.
Subscription Renewal
Cloudesire can manage subscriptions with automatic renewal (autorenew) enabled or not.
If autorenew is enabled:
- when a subscription expires, the platform automatically issues a new invoice to the customer for the next billing period
- if the customer previously decided to let the marketplace store his credit card data, Cloudesire automatically charges the invoice amount.
If autorenew is disabled:
- a few days before the subscription expiration, Cloudesire notifies the customer to remind the expiration and creates an invoice that the customer needs to pay to use the application after the subscription expiration
- if the customer doesn't renew his subscription (i.e. doesn't pay the related invoice), Cloudesire suspends the subscription instance and waits some days (the precise number is configurable in the platform) for the payment. If after this period the customer doesn't pay the invoice, Cloudesire destroys the application instance and the customer will no longer be able to access the application.
Pricing change policies for active subscriptions
During the lifetime of an active subscription, plans and extra resources of a product can be modified by the vendor.
The platform will automatically apply up-to-date prices only during the renew process of a subscription (at the end of the minimum duration period), or if the customer requests a change of plan.
If a new invoice is generated for a subscription with an order duration window that is greater than the billing period (e.g.: a product with a yearly commitment but monthly billing), the prices applied are consistent for the entire order duration window (e.g.: the whole year).
If the customer requests an upgrade of one or more extra resources, the applied prices are the same applied at the start of the duration window.
Extra resources
Upgrades / Downgrades policies
Customers can request upgrades/downgrades of previously purchased pre-paid extra-resources, by using the Cloudesire Dashboard.
- upgrades are applied immediately
- downgrades are post-poned to the first day of the next billing period
During the upgrade process, the platform calculates the scaled unit-price of the extra-resource(s) of interest, by applying the following rule:
scaled unit price = original price * (remaining hours until the end of the billing period / total hours in the billing period)
Please note that the billing engine granularity is 1 hour (the remaining hours will be rounded-up).
Then the platform will:
- subtract from the next customer's invoice the amount:
scaled_unit_price * previous extra-resources number - sum to the next customer's invoice the amount:
scaled_unit_price * new extra-resources number
In this way, the customer will be:
- proportionally "refunded" for the (future, but already paid) non-use time of the previous number of extra-resources
- charged in advance (but at a proportional/scaled price) for the future usage of the new number of extra-resources
Consumptions calculations for pay-per-use Extra-Resources
Post-paid extra-resources (AKA pay-per-use metrics) consumptions are calculated at the end of the billing period.
Depending on the specific use-case, a pay-per-use metric can be configured by specifying its:
- type: Gauge (value can arbitrarily go up and down) or Counter (value always increments)
- calculation function: Average value over time, or Peak value over time
More details are available in this section.
Gauge + Average is the more complex combination to handle during the end-of-billing-period calculations.
A typical example could be an "active-users" pay-per-use metric. Let's consider a hypothetical 30-days billing period, and the following scenario:
- the customer activated 10 users for the first 10 days
- the customer activated 10 additional users on day-10 and kept that number for the following 15 days
- the customer deactivated 5 users on day-25 and kept that number for the last 5 days
In this case, the platform will register:
- the "consumption" of 10 users for the 10 days
- the "consumption" of 20 users for the following 15 days
- the "consumption" of 15 users for the last 5 days
Given a hypothetical unit-price of 2 EUR per active-user, the final price that will be charged to the customer will be:
(10 users * 2 EUR * (10 / 30 days)) + (20 users * 2 EUR * (15 / 30 days)) + (15 users * 2 EUR * (10 / 5 days)) = 31,66 EUR
Of course, for the sake of clarity, in this example we're assuming a (very unlikely) granularity of 1 day. In reality, the platform will use a 1-hour granularity.
Please note that the calculations can be much more articulated if a complex pricing schema is configured on the extra-resource (e.g. for applying volume discounts).
Coupons
Platform Administrators, Vendors and Resellers can generate coupons for products or product plans.
Each coupon will have a unique code and a period of validity. The code is what customers need to enter in the coupon field to redeem the coupon when purchasing an application.
It's possible to specify the e-mail address of a specific user and send the coupon only to him. If the coupon is created for a specific user, the platform sends him a communication containing the coupon. It's also possible to distribute coupons outside the platform: users only need to know the code to redeem the coupon.
Cloudesire allows to generate 2 types of coupons:
- discount: when the customer uses this kind of coupon, a discount is applied to the application price;
- price override: when the customer uses this kind of coupon, a price override (usually lower) overrides the original one for the given application version (plan). A typical use case is: the vendor doesn't want to publish a public price for the application and wants to choose a different price for each customer.
Coupons can be:
- "one-time only", meaning that each coupon can only be used one time and is not reusable (even if it is transferable from one customer to another)
- "reusable", meaning that each coupon can be used more times (until its expiration date)
When a coupon is used to buy a subscription, its effect is applied to every subsequent renewal, until its eventual expiration date or until a request to upgrade the product plan.
Furthermore, Cloudesire supports an additional type of coupon:
- extended trials: when the customer uses this kind of coupon, the default trial period length (e.g. 10 days) will be replaced with the one specified in the coupon (e.g. 30 days). A coupon of this type remains valid for all the customers receiving this coupon code. This rule does not override the general rule "only one trial for each product for each customer". For each extended trials coupon, the platform administrator can allocate a budget (or plafond) which will be decreased by a certain amount every time it will be used by a customer.
Discount coupon destination
A discount coupon can be configured to be applied to:
- License only: the license cost and the setup fee (if present)
- License and extra resources: as above, plus every extra resource
- Total price: every cost line
Price override coupons are only applied to the license cost.
Bundles
Cloudesire allows Platform Administrators, and Resellers to create bundles as a composition of 2 or more products.
A bundle has the same "marketing & legal" attributes of a standard product (icon, descriptions, feature list, FAQ, screenshots, video, ToS, Privacy Policy, etc.). On top the platform allows to create several plans for the same bundle (e.g. silver, gold, platinum, etc.).
Each bundle plan is defined as a composition of product plans. Using a simple interface it's possible to specify for each of them a discount percentage; in this way, the total price of a bundle plan is calculated as the sum of all the discounted prices of all the product plans attached to it.
On the Marketplace, a bundle is shown as a normal product, highlighting the discounts, while in the ordering page the customer can have a detailed view of all the prices and the savings.
Payments
The Cloudesire platform has first-class support for Stripe payment gateway.
Platform administrators decide which methods of payment are globally available:
- Credit Cards (card data is handled by Stripe)
- SEPA direct debit (via Stripe)
- Offline payments (bank transfer or similar)
Software vendors can decide to limit the available methods of payment for each plan of their products.
Self-Billing
In some particular business scenarios it is useful to let some vendors to issue invoices from themselves, without using the Cloudesire invoicing engine.
The platform allows the admins to mark a specific product plan as self-billed, or to enable/disable globally self-billing for all the products.
In this case, when the user purchases a product, only a pro-forma invoice is generated to help the vendor emit their own invoice, and the vendor is responsible to set the payment status for every invoice emitted as self-billed.
The platform will record that the vendor should pay the fee back to the platform owner inside the revenues section.
Self-Billing for resellers
The self-billing functionality is also available for the resellers: a reseller can mark a sell-out price as self-billed for exposing the related product into his reseller-marketplace overriding the invoice generation on it.