Security you can inspect
Kill Bill runs in your infrastructure. Your billing data stays in your database, your team can read every line of code, and you decide how the system is exposed.
Battle-tested in production since 2010, including in Fortune 500 deployments.
Kill Bill runs on its own. The Aviate plugin is an optional add-on for enterprises. Either way, billing data flows only between your users and your deployment.
Overview
At a glance
Self-hosted
Kill Bill is not SaaS. You run it on-premises, in a private data center, or in your own cloud account.
Open source
Apache 2.0 license. The code is public on GitHub, so your security team can review it before deployment.
Authenticated API
Every API request is authenticated. Permissions are grouped into roles and assigned to users.
Audit trail
Kill Bill keeps track of every change: who made it, when, and what changed.
Tenant keys
Each tenant has its own API key and secret. Both are required on every call and can be rotated.
Card data stays with your gateway
Kill Bill is not a payment gateway. It stores the token your gateway returns, not the card.
Data ownership
Your data, your infrastructure
Kill Bill stores accounts, subscriptions, invoices and payments in a database you operate. MySQL, MariaDB and PostgreSQL are supported.
Your network
Deploy behind your own firewall, in your own network. No billing data goes to a third-party platform unless you send it there.
Personal data, your choice
Kill Bill does not require you to replicate your full customer profile. Accounts can be identified by an external key, allowing you to keep customer identity data in your CRM or identity system. If you choose to store names, email addresses, billing addresses or other personal data in Kill Bill, it remains in the database you operate.
Smaller compliance scope
This keeps your compliance scope small. GDPR compliance of your deployment remains your responsibility.
Data location
Sovereignty: you choose where it runs
Kill Bill and Aviate run where you decide: in your own data center or in your own cloud account, in the region your rules require.
Any infrastructure
Kill Bill runs in private data centers and in public clouds such as AWS and Azure, with Docker images, Kubernetes, or a standard Tomcat install.
Your region
You pick the region for Kill Bill, the Aviate plugin and the billing database, including Europe. Aviate does not require any production component to run in the United States.
Direct connection
With Aviate, your users' browsers talk directly to your Kill Bill deployment. Production billing data does not pass through servers operated by Kill Bill, and Kill Bill can stay behind your VPN.
What we hold
Our hosted services only hold account and access information, such as user email addresses, organization membership and software repository credentials.
Software packages
Aviate packages are distributed from repositories stored in the European Union.
European residency
The production billing plane can run entirely in European infrastructure you control. Contact us to discuss residency requirements for Aviate's hosted identity and software-distribution services.
Identity and permissions
Access control
Authentication and authorization rely on Apache Shiro. You choose where users and roles live.
Example from the Kill Bill documentation: a support role can adjust an invoice but cannot refund a payment.
Identity sources
A configuration file, the Kill Bill database (managed through the API or Kaui), LDAP, Okta, or Auth0, including JWT.
Fine-grained permissions
A support role can create accounts and adjust invoices, but cannot refund a payment.
Least privilege
Roles map authenticated users to fine-grained API permissions, allowing you to implement least-privilege access for support, finance and operations teams.
Hashed secrets
Tenant API secrets are salted and hashed before storage. User credential handling depends on the configured identity source. Local Shiro realms support configurable password hashing.
Back-office access
In Kaui, an administrator maps each user to the tenants they are allowed to see.
Aviate access controlInsider Preview
Aviate adds role-based access to its own features, with five predefined roles (admin, finance, operator, catalog manager, viewer) and custom roles. It works with Shiro or AWS Cognito.
Isolation
Multi-tenancy
One Kill Bill server and database can host many tenants, each with its own catalog, configuration and data.
Keys on every call
Each API call carries the tenant API key and secret, so Kill Bill knows which tenant is targeted and checks that the caller may access it.
Rotation
The tenant ID never changes. The API key and secret can be replaced if they are compromised.
Recommended setup
User permissions apply across tenants, and access to a tenant requires its keys. A common setup is one cross-tenant administrator who can only manage tenants, plus one administrator per tenant.
Traceability
Audit trail
Billing systems need to explain every number. Kill Bill was built for that.
| When | Who | What |
|---|---|---|
| 09:12:04 | finance-ops | INVOICE Item adjusted |
| 09:14:37 | support-cs | ACCOUNT Account created |
| 09:20:51 | checkout-api | SUBSCRIPTION Plan changed |
Illustrative example.
Every change recorded
An auditing framework records every change in the system: who, when, and what.
Named authors
Every write request carries an author name in the X-Killbill-CreatedBy header. Your application sets it, so pass the real user name.
Traceable numbers
Your finance and audit teams can trace an invoice or a payment back to the action that created it.
Card data
Payments and PCI DSS
Kill Bill connects to payment gateways through plugins. The recommended design keeps card data out of Kill Bill entirely.
Client-side tokenization, the recommended flow.
Client-side tokenization
Your website sends card details to the gateway, receives a token, and passes only the token to Kill Bill.
Server-side tokenization
It is possible, but systems that receive or transmit cardholder data become part of your PCI DSS scope. Client-side tokenization is generally preferred because it reduces the amount of your infrastructure handling card data.
No security codes
Never store CVV or similar codes. If you must keep card numbers, use a third-party vault or a proxy tokenizer.
Masked logs
A built-in log converter masks card numbers.
Your certification
Kill Bill runs today in PCI DSS compliant companies. Certification belongs to your organization. By not storing card data, you leave most of the PCI scope with your gateway.
Extensions and third parties
Plugins: payment, tax and your own code
Payment gateways, tax engines and custom logic plug into Kill Bill. Payment and tax plugins send data only to the providers you choose.
Isolated code
OSGi keeps each plugin's code and libraries separate from other plugins and from the core. Plugins run in the same JVM as Kill Bill, so review them like your own code.
Event bus and synchronous calls
Plugins can subscribe to Kill Bill's persistent external event bus for asynchronous processing. Some plugin APIs, including payment and invoice-time integrations, also execute synchronously as part of the corresponding operation.
Your providers, your accounts
Payment and tax plugins call the providers you choose, with your own accounts and credentials.
Official plugins
Only the plugins in the Kill Bill GitHub organization are officially supported. Review any third-party or custom plugin before production.
Separate logs
You can route each plugin's logs to its own file and mask card numbers they handle.
Built-in Aviate modules
Aviate includes its own catalog, coupons and tax modules, which run inside your Kill Bill like any plugin.
Transport and secrets
Encryption and secrets
Protect data in transit and at rest, and keep credentials out of plain text.
HTTPS
Enable HTTPS on Kill Bill, or terminate TLS at your load balancer. Kill Bill reads the standard X-Forwarded headers.
TLS end to end
Use TLS between your application and Kill Bill, and between Kill Bill and your payment providers.
Encrypted configuration
Encrypt sensitive configuration values, such as database passwords, with Jasypt.
Encryption at rest
You control database, volume, backup and key-management encryption using your infrastructure or cloud provider's controls.
Before going live
Production checklist
Security is shared. Kill Bill gives you the controls. How you deploy them is up to you.
- 1Keep Kill Bill off the public internet. Put it behind a firewall and a reverse proxy.
- 2Replace the default
adminaccount and password before going live. - 3Use TLS for every connection.
- 4Encrypt passwords in configuration files.
- 5Do not store card numbers or security codes in Kill Bill.
- 6Mask card numbers in your logs.
- 7Run at least two instances behind a load balancer and monitor
/1.0/healthcheck. - 8Install official plugins from the Kill Bill GitHub organization, and review any third-party plugin.
Lifecycle
Updates and support
Stay current, and get help when it matters.
Kill Bill open source
Free, Apache 2.0Community support, no SLA.
Security advisories
Security advisories are posted on the Kill Bill community mailing list. Subscribe to receive them.
Stable releases
Releases with an even minor number are the stable line, with backward-compatible APIs.
Signed artifacts
The Kill Bill package manager (KPM) installs signed release artifacts.
Aviate
EnterpriseLevel 3 support from the Kill Bill engineers.
Level 3 support
You work with the Kill Bill engineers on a dedicated Slack channel, with a first response within one business day for critical production issues, subject to your support agreement, and plan upgrades together.
Help with CVEs
Part of Aviate Level 3 support. When your security scans report a CVE, our engineers review it with you, check whether it affects your deployment, and help you fix it, usually by moving to a current release.
Aviate Health
Aviate Health monitors your deployment.
From security reviews
Questions security teams ask us
Does our billing data pass through your servers?
No. Kill Bill and the Aviate plugin run in your infrastructure, and your users' browsers connect to them directly. Our hosted services only hold account and access information.
What part of my production billing environment do you operate?
None. Kill Bill and the Aviate runtime execute in infrastructure you operate. We do not administer your production deployment, hold production Kill Bill credentials, or proxy production billing traffic. Aviate-hosted services provide identity, software distribution and related control-plane functions; they are outside the production billing data path.
Can your engineers see our production data?
No. We do not operate or administer your production systems. When we investigate an issue, we may ask you for logs, and you decide what to send.
Can we run our own penetration test?
Yes. We accept penetration tests commissioned by our customers.
Where can we host Kill Bill and Aviate?
Anywhere you choose: on-premises, in a private data center, or in your own cloud account, in any region, including Europe. See Sovereignty.
Is Kill Bill PCI DSS compliant?
Kill Bill runs today in PCI DSS compliant companies, but certification belongs to your organization. By not storing card data in Kill Bill, you leave most of the PCI scope with your payment gateway.
Is Kill Bill GDPR compliant?
Kill Bill does not require you to replicate your full customer profile, and any personal data you store in it stays in the database you operate. GDPR compliance of your deployment remains your responsibility.
How do we hear about security fixes?
Security advisories are posted on the Kill Bill community mailing list. Aviate customers with Level 3 support also get help from our engineers to assess and fix the CVEs their scans report.
How do we report a vulnerability?
Through our contact form, not a public GitHub issue. See Report a vulnerability.
Responsible disclosure
Report a vulnerability
Found a security issue? Here is how to tell us.
- Please do not open a public GitHub issue for a security problem.
- Write to us through our contact form with a description, the affected version, and steps to reproduce.
- Give us reasonable time to fix the issue before any public disclosure.
Questions from your security team?
Send us your questionnaire. We answer from the code and the documentation.