Questions on killbill

[pka...@gmail.com]

Hi team

1- Does killbill supports usage based plans/charges? I don't see this concept anywhere (do see some usage/meter related classes) or any such invoice items on http://kill-bill.org/invoicing.html

2- Does entitlement mentioned here http://kill-bill.org/entitlement.html, refers to subscription REST apis? Since i dont see any API for entitlement.

I may have more questions later, will post them here as they occur.

[pka...@gmail.com]

More Qs:

3- Does it support advance payments or 'pre-paid' products/subscriptions?

4- Does it send notifications when account balance is below some threshold? and then reminders every 'x' time-unit, till account gets suspended finally after 'y' reminders?

[Stephane Brossier]

Hi

1- Does killbill supports usage based plans/charges? I don't see this concept anywhere (do see some usage/meter related classes) or any such invoice items on http://kill-bill.org/invoicing.html

Kill Bill today does not support usage billing.

Often when talking about usage billing, one needs to make the distinction between the 'metering' piece and the 'usage' one:

* metering is the component that will handle all the request to record the usage; the complexity here is to make sure that piece scales as the # request may be quite large. We have an implementation of a 'meter' plugin: (https://github.com/killbill/killbill-meter-plugin)

* usage component. this part allows to invoice the customer based on its usage. it would require to modify the invoice code and the catalog to be able to define the usage rules. We sketched a design a while ago, but don't have any implementation yet.

2- Does entitlement mentioned here http://kill-bill.org/entitlement.html, refers to subscription REST apis? Since i dont see any API for entitlement.

The short answer is yes. 

We are currently in the process of redefining these entities and offer the ability to explicitly separate the question of entitlement with the question of subscription which drives the invoice. 

3- Does it support advance payments or 'pre-paid' products/subscriptions?

The short answer is no.

Just to make sure i understand your question:  Are you talking about the ability to let the customer pay in advance to build some credit that is later used when an invoice is generated and needs to be paid out.?

4- Does it send notifications when account balance is below some threshold? 

Today in Kill Bill:

* If customer balance is > 0, the customer owes money

* If customer balance is < 0, the customer has credit on its account it can use on subsequent invoices

Kill Bill does not send any notification itself bu you could write a plugin that listens for events and send the notification/take action from that plugin.

and then reminders every 'x' time-unit, till account gets suspended finally after 'y' reminders?

Also, we have a overdue (dunning) system built-in, which takes as an input a configuration file and takes action when certain criteria are met. An example of those can be found here:

https://github.com/killbill/killbill/blob/master/server/src/test/resources/overdue.xml

--
You received this message because you are subscribed to the Google Groups "Kill Bill developers mailing-list" group.
To unsubscribe from this group and stop receiving emails from it, send an email to killbilling-d...@googlegroups.com.
To post to this group, send email to killbil...@googlegroups.com.
Visit this group at http://groups.google.com/group/killbilling-dev.
To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-dev/a70f9589-b082-485e-941b-f4b1a11981f2%40googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[pka...@gmail.com]

Thanks Stephane.

So the usage/meter based billing is in roadmap? How far would that be? 

Even if we can add a custom item (with few details like item name, li'l description and amount) to invoice, that should be sufficient for me for now. Does KB supports that today?

For Q-3: yes, i meant like a pre-paid phone plan, where you pay in advance, and can use the service only till you have balance, may be with some grace if allowed. Its related to Q-1.

[Stephane Brossier]

On Jul 24, 2013, at 11:55 PM, pka...@gmail.com wrote:

> Thanks Stephane.
>
> So the usage/meter based billing is in roadmap?

Yes.

> How far would that be?

This is harder to answer. Our current roadmap is to stabilize what we have in terms of API. We are currently making some change around entitlement APIs and are planning to release that some time in september timeframe. ONce we are done with that we will prioritize the next items. Usage billing is on top of the list.

> Even if we can add a custom item (with few details like item name, li'l description and amount) to invoice, that should be sufficient for me for now. Does KB supports that today?

Not sure i am following. There is a description field on the invoice item. Is that what you are referring to?

>
> For Q-3: yes, i meant like a pre-paid phone plan, where you pay in advance, and can use the service only till you have balance, may be with some grace if allowed. Its related to Q-1.

Ok got it. Once we move to usage billing we will definitely address that.



Between, if you have a detailed list of requirements, we would be happy to look at them. Also, if you have any interest in contributing we can also work together and help you implement what you need.

Cheers,

S.

[pka...@gmail.com]

Today items of invoice are fixed like RECURRING, FIXED, EXTERNAL_CHARGE, and so on with their possible values being less/greater/equal to zero etc.

By "..if we can add a custom item (with few details like item name, li'l description and amount) to invoice, that should be sufficient..." i meant if i can add a custom such item with name (i.e. 'fetch/update items'), desc (i.e. 200 items updated), amount ($2.0 :- can be -ive for item-level discounts etc). 

Same sort of custom item can be added at invoice level also for other charges/discounts which applies to whole invoice not to invoice-items.

This will give KB more befitting capacity in different/unknown scenarios, since the client app can control such aspects but KB handles all billing related stuff.

I'm still trying to understand KillBill more and making it work for me, but finding it li'l hard without enough documentation. May be a simple step-by-step tutorial will help newcomers more.

I'll definitely contribute whatever i can (i have converted n embedded the one class given by Pierre into different classes with their dependencies into my app - will try to make a separate client app and post here so somebody can make use and put more into that).

I was looking more of a usage based billing, with the features KB claims it already has.

Thank you.

[Pierre-Alexandre Meyer]

[Jumping into the conversation as Stephane is out this week]

On Fri, Jul 26, 2013 at 2:09 AM, <pka...@gmail.com> wrote:

Today items of invoice are fixed like RECURRING, FIXED, EXTERNAL_CHARGE, and so on with their possible values being less/greater/equal to zero etc.

By "..if we can add a custom item (with few details like item name, li'l description and amount) to invoice, that should be sufficient..." i meant if i can add a custom such item with name (i.e. 'fetch/update items'), desc (i.e. 200 items updated), amount ($2.0 :- can be -ive for item-level discounts etc). 

Same sort of custom item can be added at invoice level also for other charges/discounts which applies to whole invoice not to invoice-items.

Indeed, you could implement usage yourself right now. If you have an external database storing the usage data (per customer per day for example), you could call Kill Bill once a week/month to generate an invoice with that data ("$20 for 10 items used in July"). Kill Bill would not only generate the invoice, but could also trigger a payment, and you would leverage the rest of the Kill Bill features (dunning/overdue emails, account balances, ability to refund, etc.).

So, if you want to go that route, you don't need a new invoice item. EXTERNAL_CHARGE is what you are looking for.

Look at the API: POST /1.0/kb/invoices/charges

The payload needs to contain:

* accountId: the Kill Bill account id

* amount: the amount for the charge

* description: any description for the invoice, for example "10 items used"

Optionally, you can also specify an invoiceId (POST /1.0/kb/invoices/<invoiceId>/charges), if you want to amend an existing invoice.

In contrary to subscription invoices (automatically generated by the system), this invoice won't trigger a payment automatically. So you could create more invoices as needed (or amend). When you are ready to make a payment for that account, you can call POST /1.0/kb/invoices/payments (the payload simply needs the accountId).

The work we want to do for usage is pretty much what I am describing, except that the external usage database would be inside Kill Bill, and the invoices and payments would be automatically generated.

I'm still trying to understand KillBill more and making it work for me, but finding it li'l hard without enough documentation. May be a simple step-by-step tutorial will help newcomers more.

Sorry to hear it. Did you try our 5-minutes tutorial (http://kill-bill.org/start.html)? Was it helpful?

Could you share a little more details on what you are trying to achieve? Maybe we could guide you through it.

 

I'll definitely contribute whatever i can (i have converted n embedded the one class given by Pierre into different classes with their dependencies into my app - will try to make a separate client app and post here so somebody can make use and put more into that).

Awesome! Looking forward to it.

--

Pierre-Alexandre Meyer

http://pub.mouraf.org/blog

[pka...@gmail.com]

Thanks Pierre. 

I thought of using same external-charge, but on the invoice page, it says: 

"EXTERNAL_CHARGE: Fixed (one-time) external charge, for items not in the catalog. This item is always positive"

and i was confused by "fixed - one time". 

This 'fixed-one-time' means its should be one time charge for the duration of the account, or one time per invoice or one-time for killbill but a KB client can add this item any no of times in an invoice?

I was not thinking to keep full usage data in my app, instead better if i could add this charge (with one line desc) to KB every time i run the operation. That way my application need to worry only about operation, and KB manages billing/invoice related stuff.

To make KB work for me: I did look at the 5-min quick start. Initially i fought a lot to make KAUI work, but got lost in ruby. Then you gave me a java client class which helped a lot. then i went thru all the doc on the site, but could not order them (what to do now and next etc- took a li'l while to understand the biz concept behind few terms and relation between). I tried to create an advanced catalog, which took a li'l fight but done now.. so i'm progressing but somewhat slow.

[Pierre-Alexandre Meyer]

On Sun, Jul 28, 2013 at 5:51 AM, <pka...@gmail.com> wrote:

I thought of using same external-charge, but on the invoice page, it says: 

"EXTERNAL_CHARGE: Fixed (one-time) external charge, for items not in the catalog. This item is always positive"

and i was confused by "fixed - one time". 

This 'fixed-one-time' means its should be one time charge for the duration of the account, or one time per invoice or one-time for killbill but a KB client can add this item any no of times in an invoice?

The wording might be confusing. It's actually none of the above.

An external charge of $5 is a line item of $5 on an invoice. It's one-time in the sense that the system won't automatically re-charge $5 the account the next month: this is the opposite of a recurring item ($10 billed every month). But an account can have as many external charges as needed during its lifetime, and you can even have multiple external charges per invoice.

I was not thinking to keep full usage data in my app, instead better if i could add this charge (with one line desc) to KB every time i run the operation. That way my application need to worry only about operation, and KB manages billing/invoice related stuff.

This separation of concerns makes total sense (all billing logic should belong in Kill Bill). Could you share a little bit your usecase regarding usage data? What kind of usage are you talking about?

If the frequency of metering (i.e. recording your "operation") is quite low, that approach can work: each time you record usage data, you can add a line item to the invoice.

If it's a high volume of metering, this won't work well. For example, if you are a telecom company and want to use Kill Bill to record minutes used on a cell phone plan, with this approach, if you generate one line item per minute of conversation, invoices can become very large (hundreds of items). This will work fine with Kill Bill but it can be confusing for your customers.

For such high volumes, what I was suggesting was to keep the usage data in a separate database, and create the line item once a day for example. In this scenario, the invoice would have a line such as "$100 used for 100 minutes on 2013-07-28", instead of 100 lines of "$1 used for 1 minute on 2013-07-28T08:00:00",  "$1 used for 1 minute on 2013-07-28T08:01:00",  "$1 used for 1 minute on 2013-07-28T08:02:00", etc.

To make KB work for me: I did look at the 5-min quick start. Initially i fought a lot to make KAUI work, but got lost in ruby. Then you gave me a java client class which helped a lot. then i went thru all the doc on the site, but could not order them (what to do now and next etc- took a li'l while to understand the biz concept behind few terms and relation between). I tried to create an advanced catalog, which took a li'l fight but done now.. so i'm progressing but somewhat slow.

If you can, feel free to share your catalog or configuration files if you want some feedback and/or need help adjusting them.

We are also going to add more detailed docs soon, but in the meantime, feel free to ask questions here!

[pka...@gmail.com]

With this clarification, I should be good for now with external-charge.

5- Does KB supports advance payments? How can i instruct KB to initiate a payment when needed (i.e. 'start' of every billing period)?

6- The meter module here (https://github.com/killbill/killbill-meter-plugin) says it aggregates usage data. How should i use meter plugin to do it? Any client example/tutorial etc? Can this plugin manage the scenario you presented (every min billing for a telecom company) and keep only aggregated-on-day(or hour etc)-basis usage item in invoice?

Thank you.

[pka...@gmail.com]

Hi Pierre/Stephane, Attached is a zip file with KB java client (eclipse project). I know this has a lot of room for improvements, but atleast something is here for java guys to start with. 

[Pierre-Alexandre Meyer]

On Mon, Jul 29, 2013 at 2:39 AM, <pka...@gmail.com> wrote:

5- Does KB supports advance payments? How can i instruct KB to initiate a payment when needed (i.e. 'start' of every billing period)?

This is the default behavior in Kill Bill for recurring charges (as defined by the catalog). At the start of each billing period, an invoice is automatically generated and a payment triggered.

 

6- The meter module here (https://github.com/killbill/killbill-meter-plugin) says it aggregates usage data. How should i use meter plugin to do it? Any client example/tutorial etc? Can this plugin manage the scenario you presented (every min billing for a telecom company) and keep only aggregated-on-day(or hour etc)-basis usage item in invoice?

This plugin is indeed designed to solve the telecom company problem I described (we started working on metering before usage). This is still alpha software however and not quite ready for production usage. It's on our roadmap, but we don't have estimates yet when this work will be done.

[Pierre-Alexandre Meyer]

On Mon, Jul 29, 2013 at 6:40 AM, <pka...@gmail.com> wrote:

Hi Pierre/Stephane, Attached is a zip file with KB java client (eclipse project). I know this has a lot of room for improvements, but atleast something is here for java guys to start with. 

Awesome work, Praveen!

I have imported it into our main repo: https://github.com/killbill/killbill-client-java

I did a few small modifications:

* search is now implemented as of 0.4.0, so I have removed the comments about it not being available

* I added a check for response code 401 (wrong credentials)

* I added the new BillingExceptionJson parsing but also kept the old behavior so you don't have to upgrade

* Minor misc. cleanups (removed main methods, etc.).

I also added a basic integration test (see TestKillBillAccount.java).

Let me know if I broke anything!

Thanks again!

[dan.la...@gmail.com]

On Monday, July 29, 2013 2:39:04 AM UTC-4, pka...@gmail.com wrote:

> 6- The meter module here (https://github.com/killbill/killbill-meter-plugin) says it aggregates usage data. How should i use meter plugin to do it? Any client example/tutorial etc? Can this plugin manage the scenario you presented (every min billing for a telecom company) and keep only aggregated-on-day(or hour etc)-basis usage item in invoice?

Did you start using this plugin? If so, what do you think of it?