Open Source Software: The Kill Bill Story

Open Source Software: The Kill Bill Story

There has been a lot of ink written about software models and why/when it makes sense to use open-source software (OSS); there was recently an interesting article about that specific topic. The short story is that such decision is based on many different factors, including the available options (OSS and non OSS), engineering organization, short term/long term choices, company DNA, … In this post, i would like to focus on our project specifically by asking two questions, one addressed to folks looking for billing and payment solutions and one to the Kill Bill team (note that i am both asking the questions and answering them for all parties, which is quite convenient…) Fictitious Journalist: “So, you are looking for billing and payment solutions, what are your choices, why Kill Bill?” In the world of billing and payments, companies are left with 3 main options (all of them with their pros/cons): 1. SAAS model This is often presented as a turn key option that will solve all your problems so you can focus on your IP and not be distracted by things that are irrelevant to your business: This statement is true in the sense that pretty much any developer using (pretty much any language of his choice) could quickly integrate with a SAAS business and start processing subscriptions, or making payments through a gateway. However, it is also misleading for the following reasons: Each business will need its special business logic and so simply using the raw apis from the SAAS will not be enough; often there is a need for another system in front of that SAAS (to implement...
Understanding payment failures

Understanding payment failures

A typical integration with a payment gateway such as Stripe looks like this: In the error handling block, you may decide to email the customer, block his access to your website, etc. Hopefully, you also keep track of these errors and generate a daily report on how many transactions fail: after all, these directly impact your bottom line. Good enough? Unfortunately, as we will see below, this approach is often too simplistic. In this particular example, the exception caught is only one of several possibilities. Looking at Stripe’s documentation specifically, CardError is thrown only for 402 – Request Failed. Other exceptions can occur, such as RateLimitError, when 429 – Too Many Requests is returned: in this case, you went over your API quota and you will want such requests to be re-submitted later. Let’s now assume we fix our code above to look like: Errors like InvalidRequestError, AuthenticationError or APIError should be closely monitored after each deployment, as they may be triggered by a recent code or configuration change. What about the black box of CardError? Let’s take a look at how we can categorize further such payment failures. On one hand, some transactions may be blocked by your payment gateway, depending on your configuration settings. Braintree for instance refers to them as Gateway Rejections. A typical example is CVV rejections: when triggering an authorization, the issuing bank will tell the gateway if the supplied CVV matches. If it doesn’t, most gateways can be configured to automatically void the transaction to prevent fraud. Another typical scenario is when your provider offers fraud detection tools: if it determines that the...
Performance Numbers

Performance Numbers

In the past year, we have done a lot of work on performance, and we already had the opportunity to describe some of that work in a previous blog entry. We now feel it is time to provide some numbers, but numbers in themselves are meaningless, unless we provide some context. Expectations and target goal: A good place to start is to look at our software stack to get a sense of any limitation: We are relying on a standard set of battle-tested open-source components (Linux, MySQL, Tomcat, Java, Ruby, and all kinds of software libraries…). The best performance numbers we could expect would be with a Tomcat handler that simply returns 200 OK. Such a deployment could achieve 1,000 or even 10,000 requests per second. Now, if the handler needs to keep some persistent state, and each request requires fetching state from a database and writing new state, the numbers could easily be divided by 10, and we would expect results in the 100 to 1,000 requests per second. Another angle is to look at existing data from the industry: Amazon, the largest US eCommerce site, processed about 400 payments/second during black Friday. Also, as Pierre mentioned in his previous blog post, typical eCommerce sites usually process a few payments per second at most; a brief calculation shows that a system processing on average 10 payments per second of $10 would already result in $8M per day or over $3B per year. Based on those numbers (what we expect to achieve and what the industry needs), we understand our target goal is somewhere in the 100 to 1,000...
Money20/20 2015 hackathon

Money20/20 2015 hackathon

We just came back from the Money20/20 hackathon in Vegas. For those who don’t know it, this event brings the entire fintech developer community under one roof for 24 hours, in order to put together new disruptive payment applications. Just as last year, we had plenty of opportunities to showcase Kill Bill, thanks to the open nature of the platform. But instead of trying to extend Kill Bill, this time, we decided to do something a little different. Ever since we started Kill Bill, Stéphane and I have been talking about what a great a fit it would be for small Yoga Studios. Surprisingly enough, most of them still manage attendance on pieces of paper (you typically have to sign a sheet before practice) and recurring billing is often done by hand (i.e. once a month, you need to come with your credit card). There are a few leaders in the industry trying to solve that problem (and similar ones for gyms, spas, etc.), but the solutions offered are expensive, too complicated (some features are available on the mobile app, others on the website) and the UX is overwhelmed by extra features, most often unneeded (scheduling, reporting, marketing, etc.). For this year’s hackathon, we developped a solution for this market: The Pink Mat. The Pink Mat is a mobile Point of Sale system, running on any iOS and Android system (we expect studios to typically install it on an iPad). New customers can come in and self-register by scanning their credit card. They can then select either one-off passes (such as a 10 Class Card) or a recurring subscription...
Kill Bill GO client library

Kill Bill GO client library

We are quite excited to announce that we created a new client library to interact with Kill Bill in GO. GO is becoming an important new player: We are seeing more and more successful projects (e.g Docker written in GO), or startups like CloudFlare embracing this new language. The declarative syntax is a bit of a pain at first, and the structure and naming of the packages is also something i am not really sold on, but the language itself is a good middle point between low level C programming and more modern code (where one does not need to think about allocating and freeing memory for instance). One of the main asset of GO are the goroutine (along with the channels), a lightweight thread abstraction that can be used to write highly concurrent programs. Our motivation (besides providing a new way to connect to Kill Bill) is based on the use of these goroutines to write Kill Bill load tests. At this stage, we only implemented a limited number of APIs, but we hope the community can pick-up the work as the need...
Kill Bill 0.14.0 Released!

Kill Bill 0.14.0 Released!

We are excited to announce our new release Kill Bill 0.14.0! The release is mostly targeted to cover all the current use cases identified in our talk , that is: Subscription As A Service Global Payment System Subscription As A Service On the Subscription As A Service side, the following areas have been enhanced: Multi-tenancy. In particular, the ability to upload per tenant config (catalog, invoice templates, invoice translations), and per plugin config (so, for instance the same stripe payment plugin could be used across multiple tenants with different set of credentials, …). Catalog Price Override. Subscriptions APIs have been enhanced to now support overriding static catalog prices, by automatically adding new catalog entries with those new prices. The price override occurs at the phase level, and allows to override both fixed and recurring prices in one or multiple phases of the plan associated with the new subscription. Ability to dynamically add new roles and admin users. We added APIs that allow to add new roles and admin users (without having to restart Kill Bill instances). This is mostly useful for deployments that rely on static shiro.ini configuration files, as opposed to LDAP (which we also provide). New plugins: Tax plugin (Avalara) Email notification plugin Global Payment System The bulk of the work has been geared towards stability and performance of our JRuby stack. Most of our payment plugins are ruby plugins, and it is therefore critical to make sure the system can handle many requests in parallel. Pierre wrote a blog about the performance work which offers more details. In addition to this core platform work, we also developed...