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,...
This post is a high level description of the architecture of Kill Bill as a billing system. The intent is to describe briefly the various core components and how they interact with one another. The diagram below shows the main core services in Kill Bill: At the bottom of the stack, we have the catalog service, whose role is to provide the catalog information that is pertinent to a given tenant. The catalog service offers an API to retrieve product information, alignment rules, prices,.. The entitlement service offers an API for managing all the entitlement information associated to a given subscription — its state (started, paused, resumed, stopped,…), its ownership, the various dates where state transition,… The entitlement system offers a different view than what is reflected in the invoices to allow fine tuning of what should be billed versus how the service is provided. In addition to that API, it will generate (persistent) bus events that other services can register to. The invoice service offers an API to retrieve past invoices, make any adjustments, or even trigger future invoices. In addition to that API, it will generate bus events that other services can register to. The payment system offers an API to retrieve past payment/refund information or to trigger new payments/refunds. In addition to that API, it will also generate bus events. The overdue system is a generic system that is driven through a configuration, to take action when payments are failing and users end up not paying. A complex set of phases can be implemented to gradually terminate the service, notify the users, … if needed. It also offers an...
