We are very eager to announce the new Kill Bill 0.18.x release train (current version at the time of this blog is 0.18.2). Our last announcement for a ‘major’ release (see current Kill Bill versioning scheme) was almost a year ago . Since this release somehow coincides with the end of the year, it feels natural to not only review what it contains but also to provide an overview of what happened through 2016. Obviously, a lot has happened in a year and this blog post will just touch the surface of some of the main things we (and the community) achieved. Main New Features: At this point the platform is already pretty features-rich, and each new feature brings further complexity and also has the potential to destabilize the system. So, we have to balance fulfilling the desire of some of our (most loyal) users with the stability and risk associated with such new features. Some of the main features we added are: Hierarchical Account Shopping Card Apis Blocking State Abstraction Migration Apis (along with migration guide) Subscription Bill cycle day (BCD) change Subsystem/Feature Rework: With more adoption comes more bug reports, use cases we never thought of, … and so a large part of the work we did throughout the year was about hardening and enhancing the various sub-modules. Catalog: A lot of effort was invested in the catalog to address some of the shortcomings (e.g. ability to have plans of different shapes on the same pricelist), provide apis to dynamically add Plans on the current version of a catalog, harden validation, and greatly improve performance for large catalogs....
Until now, Kill Bill only allowed to configure the Bill Cycle Day (BCD) attached to each subscription through the use of billing alignment catalog rules. As a reminder, the BCD defines the day when a specific subscription gets billed. For instance assuming customers get billed in advance, then creating a monthly subscription on 6/1/2016 with a BCD=1 would generate a first invoice on the 6/1/2016 for the month of June, and then a next invoice on July 1st for the month of July, etc… In the current scheme, there are 3 different possible billing alignment policies, that are configured using special catalog rules: ACCOUNT: All subscriptions whose Plan is defined with an ACCOUNT alignment will use the same account level BCD. This allows to group all subscriptions for an account on the same invoice. The BCD is either set using api, or if not set, the system will infer that BCD when the first subscription on the account is created (by looking at the first Phase in the Plan whose recurring price is not 0). SUBSCRIPTION: The BCD is based on the subscription startDate and by also looking at the first Phase in the Plan whose recurring price is not 0. BUNDLE: This is similar to the SUBSCRIPTION case but the system will use the start date of the base subscription to compute the BCD. With the existing mechanism, the administrator configures once the various policies in the catalog and then everything happens automatically. This approach is convenient but rather static (does not allow to change a BCD for an existing subscription). In order to provide a more dynamic...
Back in the days, when we started the design for Kill Bill, some of the first discussions we had were centered around catalog (definition of products, prices, behavior associated to each product or transition from one product to another, …). We had lots of use cases that we knew about such as providing support for trials and discount, grouping things on one or multiple invoices, providing support for subscription dependencies (add-ons), international support, … Our initial implementation was based on a static set of XML files, where each file represents a specific version of the catalog. XML proved to be a fairly good choice to represent our various abstractions and provide the flexibility we wanted through the use of various catalog rules. However, we also knew that our knowledge was incomplete, but the idea was that, as we would discover new use cases we could enhance our object model. And this statement also happened to be true: when we started to implement some of the usage billing case scenarios, we added new usage sections in our catalog XML and again the XML representation was powerful enough to cover all the use cases we came about. When we moved to fully implement the multi-tenancy feature, we then needed to have each tenant own its catalog. The XML based model was still a good fit. The only difference here, was that the catalog was not something that was shared across tenants any longer, but something that administrators of the various tenants could configure through the use of endpoints. Then, one day, on the mailing list we had a request to support...
As a follow-up to our Payments Tech Talk at Groupon, I would like to go in more details over the performance work we have been working on and what you can expect in the next release. Kill Bill is not designed to handle tens of thousands of requests per second. You won’t have that type of traffic, even if you are a large company. Think about it: customers don’t often create or change their subscriptions. Even in an e-commerce shopping cart scenario, the rate of checkout is fairly low: 10 payments per second of $10 already results in $8M per day or over $3B per year. What we care about though is being able to support bursts: while you might typically handle 10 payments per minute, or even per hour, a limited-time promotion might result in 50 or 100 transactions per second for a period of a day or two. Additionally, we want to minimize latency. While the lower bound will eventually be dictated by the gateway, we want to optimize the overhead added by Kill Bill as it creates audit logs, checks the overdue status, moves the payment to the next state in its automaton, etc. To do so, we regularly load test scenarii such as the following: create a new account, add a payment method and trigger a payment. This would simulate a new user going to your site and proceeding to the checkout page, which is what would typically happen during peak demand as described above. During and after the test, we extract various metrics. First, we look at data from the Kill Bill profiling framework,...
Overview Kill Bill has been designed from the beginning as a multi-tenant system; that is, on one physical Kill Bill deployment, we can have multiple (tenant) instances of Billing/Payment solutions, completely independant with one another. Each of those tenants will have its own catalog and internationalization translations, and will only have access to its own data. In addition to the multi-tenancy, Kill Bill also requires authentication and implements authorization validation on each request. Logically , the multi-tenancy feature and the authentication/authorization are two separate concepts: a given user has access to a (some) specific tenant(s) and that user has some specific set of permissions. The current implementation keeps those two orthogonal, but in the future we may offer the ability to configure the set of permissions associated to a specific user on a per-tenant basis. API Calls When making API calls against Kill Bill, each request needs to pass: The credentials or the sessionId required for the authentication (through HTTP basic authentication), The apiKey (X-Killbill-ApiKey) and apiSecret (X-Killbill-ApiSecret) for the tenant On each request, Kill Bill will validate the credentials are correct (or if there is a sessionId, the validity of that session), The apiKey and apiSecret will be used to retrieve the tenantId and validate the user has access to that tenant. So in the end, only a valid user with the right set of permissions will be able to perform an API call against a tenant she has access to. KAUI Now, let’s look at what happens, when the user is interacting with Kill Bill using KAUI (Kill Bill admin UI): Authentication: User first needs to login,...
In a billing system, dates and times are a critical part of the system, and yet dealing with date and time certainly has its challenges. Let’s start by saying that Kill Bill has a granularity of a day– which means it will not invoice for something smaller than a day. Let’s take a look at where those dates and time elements appear in Kill Bill. This all begins at the API level; In most operations, Kill Bill allows to specify both either a date or a fully qualified date, time and timezone, that is, a well defined point in time, or datetime for short. Specifying a date is often easier for the user because one may want to cancel a subscription on the 25th of the month and not necessarily exactly at 2014-10-25T5:48:56.000Z. However, specifying a date also means that this date will be subject to interpretation, because it is imprecise and also varies for different people on different place on the earth. So the user of the API also needs to know how the date is interpreted– more details below. Then, the data generated by the system will also start exposing some dates; for instance, the next date at which the subscription will be invoiced, or the date range for the some specific invoice. Finally, Kill Bill is also driven by future notifications; for instance, a future notification to charge a recurring subscription on its next billing date will happen on a specific point of time, but the point of time needs not to be precise, as long as it is within the 24 hours period of time...
