Kill Bill use cases

[nep...@gmail.com]

Hi

I am currently looking into implementing Kill Bill for our subscription management and billing purposes and I do have some questions regarding our use cases:

1. In our business domain we often deal with one-off purchase for which the price is only determined at the time of the purchase. So we cannot pre-define the price in the catalog file. As far as I've seen, such one-off purchases are called "STANDALONE" products in Kill Bill. Is there a way to actually define the price of such a product only at purchase time (ie. when adding the purchase to an account over the API)?

2. Can we somehow append additional metadata to defined products (eg. something like a product subscription or more detailed product name)? If yes, would this also be possible to do at purchase time instead of having it in the catalog (related to question #1). It seems that the custom fields might be what we're looking for but unfortunately I don't understand on how to use them.

3. We would like to feed our store frontend from the data which is available in Kill Bill. I did not yet find a way to directly query the REST API for products which are currently available for purchase for the current customer (eg. available base products or addons), other than first querying the catalog and the current subscriptions of an account and then determining the available products by correlating these sources. Is there a simpler way?

4. Can Kill Bill model a catalog where an account can only ever have at most one base subscription? In other words, is there a way to model conflicts between different products, especially base products?

Sorry for the amount of questions. I appreciate every response that clarifies some of them.

Thanks,
Dominik

[stephane brossier]

Dominik,

On Thu, Feb 25, 2016 at 1:13 AM, Dominik Meister <nep...@gmail.com> wrote:

Hi Stephane

stephane brossier [Wed, Feb 24, 2016 at 04:59:18PM -0800]:
>    Dominik,
>    See answers inlined. Also in the future, could please use the

Thanks a lot for your reply. I thought I did post to the mailing list.
I've used the google groups web interface at
https://groups.google.com/forum/#!forum/killbilling-users. Obviously I
did it wrong somehow (although I can see my post on the google groups
site).

Nope you did not do anything wrong ;-) I am the one was mistaken...

Let us know how that goes,

Stéphane

>    On Wed, Feb 24, 2016 at 6:16 AM, <[2]nep...@gmail.com> wrote:
>
>      Hi
>      I am currently looking into implementing Kill Bill for our
>      subscription management and billing purposes and I do have some
>      questions regarding our use cases:
>      1. In our business domain we often deal with one-off purchase for
>      which the price is only determined at the time of the purchase. So
>      we cannot pre-define the price in the catalog file. As far as I've
>      seen, such one-off purchases are called "STANDALONE" products in
>      Kill Bill. Is there a way to actually define the price of such a
>      product only at purchase time (ie. when adding the purchase to an
>      account over the API)?
>

>    Yes, there is price override capability defined in the catalog which
>    you can use when you create your subscriptions. This allow to override
>    catalog price entries (both fixed and recurring price associated with
>    each Phase of your Plan). We have some [3]tests written in ruby to
>    highlight the api.
>    Â

Great! I just found that on the POST /1.0/kb/subscriptions API call.

>
>      2. Can we somehow append additional metadata to defined products
>      (eg. something like a product subscription or more detailed product
>      name)? If yes, would this also be possible to do at purchase time
>      instead of having it in the catalog (related to question #1). It
>      seems that the custom fields might be what we're looking for but
>      unfortunately I don't understand on how to use them.
>

>    Yes you can use custom fields to append arbitrary key/value parameters
>    to objects created by kill Bill. In your case, you could custom-field
>    the subscription object. The api you are looking for can be found
>    [4]here.Â

OK, we are going to look into the custom field usage a bit more.

>
>      3. We would like to feed our store frontend from the data which is
>      available in Kill Bill. I did not yet find a way to directly query
>      the REST API for products which are currently available for purchase
>      for the current customer (eg. available base products or addons),
>      other than first querying the catalog and the current subscriptions
>      of an account and then determining the available products by
>      correlating these sources. Is there a simpler way?
>

>    There is an [5]endpoint to query the catalog; that should provide info
>    about which products are available (and for each BASE product, which
>    ADD_ONs are already included or available). I am not sure i understand
>    the correlation part? Or is the question around displaying for a given
>    customers which ADD_ONs are available based on the Plan attached to his
>    current subscription(s) ?
>    Â

Yes, we'd actually like to control our web frontend from the data in
Kill Bill. So if a customer has already subscribed to a base package
we need to find out which add-on packages to display as available on the
frontend. Of course we could do that outside of Kill Bill, but given
that Kill Bill has the whole catalog definition and knows the account's
current subscriptions, I think it would make sense to directly retrieve
the information from there.

>
>      4. Can Kill Bill model a catalog where an account can only ever have
>      at most one base subscription? In other words, is there a way to
>      model conflicts between different products, especially base
>      products?
>

>    There are two pieces:
>    1. The definition (define which products have such constraints). It
>    could belong to catalog but today there is not supported.
>    2. The enforcement. Provided the definition exists somewhere, the
>    enforcement could easily happen on the client side (or by using the
>    entitlement plugin api to intercept the subscription call, but that
>    seems complicated for your use case)
>    Stéphane
>    Â

Yes, I think we are going to enforce the rule outside of Kill Bill.

>
>      --
>      You received this message because you are subscribed to the Google
>      Groups "Kill Bill users mailing-list" group.
>      To unsubscribe from this group and stop receiving emails from it,
>      send an email to [6]killbilling-us...@googlegroups.com.
>      To post to this group, send email to
>      [7]killbill...@googlegroups.com.
>      Visit this group at
>      [8]https://groups.google.com/group/killbilling-users.
>      To view this discussion on the web visit
>      [9]https://groups.google.com/d/msgid/killbilling-users/7808067b-4bac
>      -44b7-a134-b9b1f2d55561%40googlegroups.com.
>      For more options, visit [10]https://groups.google.com/d/optout.
>
> References
>
>    1. https://groups.google.com/forum/#!forum/killbilling-users
>    2. mailto:nep...@gmail.com
>    3. https://github.com/killbill/killbill-integration-tests/blob/master/killbill-integration-tests/core/test_price_override.rb#L7
>    4. https://github.com/killbill/killbill/blob/master/jaxrs/src/main/java/org/killbill/billing/jaxrs/resources/SubscriptionResource.java#L608
>    5. https://github.com/killbill/killbill/blob/master/jaxrs/src/main/java/org/killbill/billing/jaxrs/resources/CatalogResource.java#L131
>    6. mailto:killbilling-users%2Bunsu...@googlegroups.com
>    7. mailto:killbill...@googlegroups.com
>    8. https://groups.google.com/group/killbilling-users
>    9. https://groups.google.com/d/msgid/killbilling-users/7808067b-4bac-44b7-a134-b9b1f2d55561%40googlegroups.com
>   10. https://groups.google.com/d/optout

--
Dominik Meister
* http://www.meisternet.ch/~dm/
* My public GnuPG key is available at http://www.meisternet.ch/~dm/gpg/pub.txt

[Dominik Meister]

Hi Stephane

stephane brossier [Wed, Feb 24, 2016 at 04:59:18PM -0800]:
> Dominik,
> See answers inlined. Also in the future, could please use the

Thanks a lot for your reply. I thought I did post to the mailing list.
I've used the google groups web interface at
https://groups.google.com/forum/#!forum/killbilling-users. Obviously I
did it wrong somehow (although I can see my post on the google groups
site).

> On Wed, Feb 24, 2016 at 6:16 AM, <[2]nep...@gmail.com> wrote:
>

> Hi
> I am currently looking into implementing Kill Bill for our
> subscription management and billing purposes and I do have some
> questions regarding our use cases:
> 1. In our business domain we often deal with one-off purchase for
> which the price is only determined at the time of the purchase. So
> we cannot pre-define the price in the catalog file. As far as I've
> seen, such one-off purchases are called "STANDALONE" products in
> Kill Bill. Is there a way to actually define the price of such a
> product only at purchase time (ie. when adding the purchase to an
> account over the API)?
>

> Yes, there is price override capability defined in the catalog which
> you can use when you create your subscriptions. This allow to override
> catalog price entries (both fixed and recurring price associated with
> each Phase of your Plan). We have some [3]tests written in ruby to
> highlight the api.
> Â

Great! I just found that on the POST /1.0/kb/subscriptions API call.

>

> 2. Can we somehow append additional metadata to defined products
> (eg. something like a product subscription or more detailed product
> name)? If yes, would this also be possible to do at purchase time
> instead of having it in the catalog (related to question #1). It
> seems that the custom fields might be what we're looking for but
> unfortunately I don't understand on how to use them.
>

> Yes you can use custom fields to append arbitrary key/value parameters
> to objects created by kill Bill. In your case, you could custom-field
> the subscription object. The api you are looking for can be found
> [4]here.Â

OK, we are going to look into the custom field usage a bit more.

>

> 3. We would like to feed our store frontend from the data which is
> available in Kill Bill. I did not yet find a way to directly query
> the REST API for products which are currently available for purchase
> for the current customer (eg. available base products or addons),
> other than first querying the catalog and the current subscriptions
> of an account and then determining the available products by
> correlating these sources. Is there a simpler way?
>

> There is an [5]endpoint to query the catalog; that should provide info
> about which products are available (and for each BASE product, which
> ADD_ONs are already included or available). I am not sure i understand
> the correlation part? Or is the question around displaying for a given
> customers which ADD_ONs are available based on the Plan attached to his
> current subscription(s) ?
> Â

Yes, we'd actually like to control our web frontend from the data in
Kill Bill. So if a customer has already subscribed to a base package
we need to find out which add-on packages to display as available on the
frontend. Of course we could do that outside of Kill Bill, but given
that Kill Bill has the whole catalog definition and knows the account's
current subscriptions, I think it would make sense to directly retrieve
the information from there.

>

> 4. Can Kill Bill model a catalog where an account can only ever have
> at most one base subscription? In other words, is there a way to
> model conflicts between different products, especially base
> products?
>