subscription period in days

[nsi...@gmail.com]

Hi Pierre
Doc says "When durations are specified in days Kill Bill will not allow a recurring price".
I need to make plan for weekly or daily subscription. Please let me know if there is any work around to bill this kind plan.

Regards,
Nitin

[Pierre-Alexandre Meyer]

On Mon, Oct 28, 2013 at 4:27 AM, <nsi...@gmail.com> wrote:

Doc says "When durations are specified in days Kill Bill will not allow a recurring price".

Just to clarify:

* For recurring (evergreen) phases, only MONTHLY, QUARTERLY and ANNUAL billing periods are supported. In that case, the duration is UNLIMITED.

* For non-recurring (fixed-length) phases, only NO_BILLING_PERIOD billing period is supported but the duration can be measured in DAYS, MONTHS or YEARS.

I need to make plan for weekly or daily subscription. Please let me know if there is any work around to bill this kind plan.

Could you describe your use-case in more details?

Note that a daily subscription for example would result in invoicing and charging a customer on a daily basis. Is this what you have in mind?

--

Pierre

[nsi...@gmail.com]

I am working on a mobile based subscription model where billing is very small.
Say a news provider push messages to users on their mobile. For this user can subscribe to a monthly, weekly, 3 day or daily plan. Periodically user will be charged for its opted plan. If user don't have enough money for its opted plan then plan should degrade to a lower duration plan for that particular cycle. So for daily plan we could be charging a customer on a daily basis but yes duration of days is required for my use case.

Regards,
Nitin

[Pierre-Alexandre Meyer]

On Mon, Oct 28, 2013 at 8:47 AM, <nsi...@gmail.com> wrote:

I am working on a mobile based subscription model where billing is very small.
Say a news provider push messages to users on their mobile. For this user can subscribe to a monthly, weekly, 3 day  or daily plan. Periodically user will be charged for its opted plan. If user don't have enough money for its opted plan then plan should degrade to a lower duration plan for that particular  cycle. So for daily plan we could be charging a customer on a daily basis but yes duration of days is required for my use case.

The lowest recurring granularity supported by the system is the month, but I'm not sure that having a daily granularity would solve your problem, as it looks more like usage billing.

I am still trying to fully understand your scenario. Are you going to charge in advance or in arrears? Are you going to consume "credits" as you push messages out, or are you going to charge and trigger a payment for each message?

Regarding the degradation logic, you could write a Kill Bill plugin to handle this logic to auto-downgrade your customers based on the account balance.

--

Pierre

[nsi...@gmail.com]

I have a payment gateway which is linked to users mobile account now mobile account can be prepaid or postpaid. Whenever a user subscribes for a service he is going to charged from his prepaid/postpaid account and recurring bill will be done till he unsubscribes. Tenant will be notified for user's status and he will provide its content on the basis of that.
Now for mobile postpaid, there will be no issues but for prepaid micro-billing is required.
Plan price will vary on the basis of period therefore I needed granularity at number of days. Can I make a plugin to dilute the granularity or it's a limitation of the system. I am not clear about the problem with granularity on number of days. Please help me understanding the subscription period.

regards,
Nitin

[Pierre-Alexandre Meyer]

On Tue, Oct 29, 2013 at 12:37 AM, <nsi...@gmail.com> wrote:

Now for mobile postpaid, there will be no issues but for prepaid micro-billing is required.

For micro-billing, it seems easier to use the charge API (POST /1.0/kb/invoices/charges):

  http://killbill.github.io/killbill-docs/userguide.html#_apis_7

Your application can simply call this endpoint each time the messages are sent.

Plan price will vary on the basis of period therefore I needed granularity at number of days. Can I make a plugin to dilute the granularity or it's a limitation of the system. I am not clear about the problem with granularity on number of days. Please help me understanding the subscription period.

It is currently a limitation of the system, which supports a billing cycle being a multiple of months. Changing it to a daily granularity could be done, although we need to think it through (e.g. review the invoice pro-ration calculations, MRR computation, etc.).

 

--

Pierre

[nsi...@gmail.com]

Hi Pierre
I am trying to dilute the granularity to weekly I have changed the billingPeriod to
public enum BillingPeriod {
MONTHLY(1,3),
QUARTERLY(3,3),
ANNUAL(12,3),
NO_BILLING_PERIOD(0,3),
WEEKLY(1,2),
BIWEEKLY(2,2);

private final int granuality;
private final int numberOfMonths;

BillingPeriod(final int numberOfMonths,final int granuality) {
this.numberOfMonths = numberOfMonths;
this.granuality=granuality;
}

public int getNumberOfMonths() {
return numberOfMonths;
}
public int getGranuality(){
return granuality;
}
}
and modified the inadvancebillingmode and InvoiceDateUtil to put switches on granuality.

Please let me know if I am heading in the right direction.

regards,
Nitin

[Stephane Brossier]

Nitin,


Could you describe a bit more what you have in mind? For one thing i am confused about your enum? Why does WEEKLY and BI_WEEKLY respectively get a 1 and 2 MONTHS? And how do you plan to use the granularity?

Additional question: Is your intent to merge those changes in the main branch-- the reason why i am asking is because our main roadmap right now goes towards stabilization of the API and the system itself and certainly not adding more functionality? Or are you just asking for guidance on how to tweak the system to fill your immediate needs-- which we are happy to help you with.

Regards,

Stéphane

> --
> 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 killbilling-us...@googlegroups.com.
> To post to this group, send email to killbill...@googlegroups.com.
> Visit this group at http://groups.google.com/group/killbilling-users.
> To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/b8c6771d-39bf-42e6-a8fc-ab2ae6d28c18%40googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.

[nsi...@gmail.com]

Hi Stéphane
I know you are planing to release 1.0 and thats why I am trying to tweak the system for my requirement of less than a month myself. If works out well I would be happy to contribute whenever the system will be open to this feature. I was looking to tweak in such a way that I could merge it with 1.0 and thats why I was looking for architectural guidance.
BillingPeriod code is a ugly fix for weekly period in which i reused numberofmonth as number in granule unit.
so for Weekly its granularity level 2 and numberofmonth depicts number of week (1) and BIWeeekly is level 2 and numberofmonth depicts 2 weeks for granularity the level is 3. I will refactor it and rename later.

in the invoicedateutil I have placed switches on the basis of granularity like

switch(billingPeriod.getGranularity()){
case 1:
proposedDate = previousBillCycleDate.plusDays(numberOfPeriods * billingPeriod.getNumberOfMonths());
break;
case 2:
proposedDate = previousBillCycleDate.plusWeeks(numberOfPeriods * billingPeriod.getNumberOfMonths());
break;
default :
proposedDate = previousBillCycleDate.plusMonths(numberOfPeriods * billingPeriod.getNumberOfMonths());
}

regards,
Nitin

[Pierre-Alexandre Meyer]

On Tue, Nov 12, 2013 at 12:05 AM, <nsi...@gmail.com> wrote:

BillingPeriod code is a ugly fix for weekly period in which i reused numberofmonth as number in granule unit.

so for Weekly its granularity level 2 and numberofmonth depicts number of week (1) and BIWeeekly is level 2 and numberofmonth depicts 2 weeks for granularity the level is 3. I will refactor it and rename later.

How about something like (to make it more obvious):

  public enum BillingPeriodGranularity {

        DAY,

        WEEK,

        MONTH

    }

    public enum BillingPeriod {

        WEEKLY(1, BillingPeriodGranularity.WEEK),

        BIWEEKLY(2, BillingPeriodGranularity.WEEK),

        MONTHLY(1, BillingPeriodGranularity.MONTH),

        QUARTERLY(3, BillingPeriodGranularity.MONTH),

        ANNUAL(12, BillingPeriodGranularity.MONTH),

        NO_BILLING_PERIOD(0, BillingPeriodGranularity.MONTH);

        private final int number;

        private final BillingPeriodGranularity granularity;

        BillingPeriod(final int number, final BillingPeriodGranularity granularity) {

            this.number = number;

            this.granularity = granularity;

        }

        public int getNumber() {

            return number;

        }

        public BillingPeriodGranularity getGranularity() {

            return granularity;

        }

    }

Note that besides modifying InvoiceDateUtils (pro-rations and BCD calculations), you also need to change the way the service period end date is computed in InAdvanceBillingMode.

--

Pierre

[nsi...@gmail.com]

Thanks I after making changes have tested for weekly and its working fine.

[nsi...@gmail.com]

> Regarding the degradation logic, you could write a Kill Bill plugin to handle this logic to auto-downgrade your customers based on the account balance.
>
> --
>
> Pierre

Can I give extension of days on the basis of money in the payment in case of low balance. For example, lets a user has 6 INR in his mobile prepaid account at the time 10 INR subscription renewal is triggered. Gateway will response not sufficient balance, current balance 6 INR. It is required to give one time 2 week extension and charge 5 INR. After 2 weeks the same process need to repeat. Downgrading will make the billing cycle permanent of lower period.

regards,
Nitin

[Pierre-Alexandre Meyer]

On Fri, Nov 15, 2013 at 7:24 AM, <nsi...@gmail.com> wrote:

Can I give extension of days on the basis of money in the payment in case of low balance. For example, lets a user has 6 INR in his mobile prepaid account at the time 10 INR subscription renewal is triggered. Gateway will response not sufficient balance, current balance 6 INR. It is required to give one time 2 week extension and charge 5 INR. After 2 weeks the same process need to repeat. Downgrading will make the billing cycle permanent of lower period.

 

Payment retries will happen automatically, as long as the payment plugin returns an ERROR status (see PaymentInfoPlugin).

Stephane is more familiar than I am with the payment code, so I'll let him correct me if I'm wrong here, but I believe we don't support payment retries on partial payments today. Looking at the code though, we may be able to add this feature by creating a future notification in case of payment success if the returned paid amount is lower than the submitted payment amount. It seems that the overdue system already refreshes the overdue status when receiving a PaymentInfoInternalEvent event, so overdue would still be able to see the incomplete payment.

As far as payment retries go, check http://killbill.github.io/killbill-docs/userguide.html#configuration-payment for system properties on how to configure the retries (frequency, ...).

You probably also want to configure the overdue system to e.g. block the entitlement after a few weeks if there is still a balance. See https://github.com/killbill/killbill/blob/master/server/src/test/resources/overdue.xml for a configuration example.

--

Pierre

[Stephane Brossier]

On Nov 15, 2013, at 4:41 AM, Pierre-Alexandre Meyer <pie...@kill-bill.org> wrote:

On Fri, Nov 15, 2013 at 7:24 AM, <nsi...@gmail.com> wrote:

Can I give extension of days on the basis of money in the payment in case of low balance. For example, lets a user has 6 INR in his mobile prepaid account at the time 10 INR subscription renewal is triggered. Gateway will response not sufficient balance, current balance 6 INR. It is required to give one time 2 week extension and charge 5 INR. After 2 weeks the same process need to repeat. Downgrading will make the billing cycle permanent of lower period.

 

Payment retries will happen automatically, as long as the payment plugin returns an ERROR status (see PaymentInfoPlugin).

Stephane is more familiar than I am with the payment code, so I'll let him correct me if I'm wrong here, but I believe we don't support payment retries on partial payments today. Looking at the code though, we may be able to add this feature by creating a future notification in case of payment success if the returned paid amount is lower than the submitted payment amount. It seems that the overdue system already refreshes the overdue status when receiving a PaymentInfoInternalEvent event, so overdue would still be able to see the incomplete payment.

Actually today Kill Bill does not support partial payments. Either payment is successful -- with the amount provided-- or it fails. 

[nsi...@gmail.com]

On Monday, October 28, 2013 1:57:52 PM UTC+5:30, nsi...@gmail.com wrote:

Can I play with 2 plans say one with one with evergreen and another with trial(partial payment with days duration)+evergreen. subscribe user to first plan and during renewal if insufficient amount trigger cancel plan along with invoice and switching to second plan. Or can I close the invoice with insufficient balance and trigger a new invoice do the payment and move next resubscription payment event to days bought.
Can you give me some pointers if I have to modify the code as per this usecase(implementing paritial payment).

regards,
Nitin

[Pierre-Alexandre Meyer]

On Sun, Nov 17, 2013 at 11:33 PM, <nsi...@gmail.com> wrote:

Can I play with 2 plans say one with one with evergreen and another with trial(partial payment with days duration)+evergreen. subscribe user to first plan and during renewal if insufficient amount trigger cancel plan along with invoice and switching to second plan.

I wouldn't go with this approach. If nothing else, this will be weird from an Analytics standpoint (it will add noise with plan changes in your reports) and might lead to confusing pro-rations.

 

Or can I close the invoice with insufficient balance and trigger a new invoice do the payment and move next resubscription payment event to days bought.

You can close the invoice by tagging the invoice with the WRITTEN_OFF tag:

https://github.com/killbill/killbill-api/blob/master/src/main/java/com/ning/billing/util/tag/ControlTagType.java

Can you give me some pointers if I have to modify the code as per this usecase(implementing paritial payment).

We started talking about it with Stephane on how to do it. Let us get back to you with pointers.

Alternatively, would it be possible to use credits for this? If the invoice balance is 10 INR but the mobile pre-paid account has only 6 INR, the plugin could still debit the 6 INR from the account and add them as credits to the Kill Bill account. You should then mark the payment as failed for Kill Bill and the next time the payment system will re-try the payment (this is configurable), it will try to charge the difference.

By the way, did you figure out how you're going to do the automatic downgrades? Will you use some features of the built-in overdue system or will you simply drive it from your plugin?

-- 

Pierre

[Pierre-Alexandre Meyer]

On Mon, Nov 18, 2013 at 5:38 AM, phoenix <nsi...@gmail.com> wrote:

I'll look forward for the outcome of your discussion with stephane

There is no real limitation in Kill Bill regarding supporting partial payments, except maybe for the fact that some of the APIs need to change (e.g. return a list of payments instead of one payment for a given invoice).

We'll be glad to take a pull request if you decide to implement it. We created the following ticket for tracking purposes: https://github.com/killbill/killbill/issues/125

--

Pierre

[nsi...@gmail.com]

Yes I'll do that.
Can you help me understanding the invoice payment overdue relationship.
thanks and regards,
Nitin

[Pierre-Alexandre Meyer]

On Tue, Nov 19, 2013 at 8:00 AM, <nsi...@gmail.com> wrote:

Can you help me understanding the invoice payment overdue relationship.

It looks like our userguide doesn't have a section on the overdue system yet. We will add it, but in the meantime, here's how it works:

Each time a payment success or error happens, or an invoice is adjusted, the overdue system will react to it. Its actions depend on a special configuration file (here's an example: https://github.com/killbill/killbill/blob/master/server/src/test/resources/overdue.xml).

This configuration file describes overdue states through which the account will go depending on certain conditions, such as the total number of unpaid invoices, the amount of unpaid invoices, the time lapsed since the earliest unpaid invoice, etc. (see https://github.com/killbill/killbill/blob/master/overdue/src/main/java/com/ning/billing/overdue/config/DefaultCondition.java).

For each stage, you can configure actions that the overdue system will take, such as blocking entitlement changes (e.g. disallowing upgrades if the account has an unpaid invoice), canceling the entitlement, blocking the billing, etc. (see https://github.com/killbill/killbill/blob/master/overdue/src/main/java/com/ning/billing/overdue/config/DefaultOverdueState.java).

For example, you could configure it to block access to the entitlement after 30 days since the earliest unpaid invoice and cancel it after 60 days.

Let me know if this makes sense or if we can help you write your configuration file.

--

Pierre

[valin...@gmail.com]

Is something like this coming to killbill? I also need customized billingperiods. In my case bi-annual. Is recompiling with the changes I need my only option for the foreseeable future?

[Pierre-Alexandre Meyer]

On Tue, Jul 28, 2015 at 5:58 PM, <valin...@gmail.com> wrote:

Is something like this coming to killbill?  I also need customized billingperiods.  In my case bi-annual.  Is recompiling with the changes I need my only option for the foreseeable future?

We have no plan in the short term to introduce new billing periods, but feel free to submit a Pull Request if you have some time to work on it. The mentioned change in the BillingPeriod enum and new regression tests should hopefully be all that's needed.

Cheers,

--

Pierre

[suha...@poynt.co]

Hi Pierre,

I noticed the DAILY billing period in BillingPeriod class. We are using the following killbill jars - killbill-client-java-0.40.5.jar and killbill-api-0.50.jar.
public enum BillingPeriod {

DAILY(Period.days(1)),
WEEKLY(Period.weeks(1)),
BIWEEKLY(Period.weeks(2)),
THIRTY_DAYS(Period.days(30)),
MONTHLY(Period.months(1)),
QUARTERLY(Period.months(3)),
BIANNUAL(Period.months(6)),
ANNUAL(Period.years(1)),
BIENNIAL(Period.years(2)),
NO_BILLING_PERIOD(Period.ZERO);

private final Period period;

BillingPeriod(final Period period) {
this.period = period;
}

public Period getPeriod() {
return period;
}
}

I created a plan with 'DAILY' billing period and subscribed to it and tried to generate the invoice. I see the following in the log file (which reflects daily subscription) . Looks like DAILY is supported. Could it be because we are using a older version of killbill (not sure what the latest version is)

RECURRING{startDate=2018-04-11, endDate=2018-04-12, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-12, endDate=2018-04-13, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-13, endDate=2018-04-14, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-14, endDate=2018-04-15, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-15, endDate=2018-04-16, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-16, endDate=2018-04-17, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-17, endDate=2018-04-18, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-18, endDate=2018-04-19, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-19, endDate=2018-04-20, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-20, endDate=2018-04-21, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-21, endDate=2018-04-22, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-22, endDate=2018-04-23, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-23, endDate=2018-04-24, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-24, endDate=2018-04-25, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-25, endDate=2018-04-26, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-26, endDate=2018-04-27, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-27, endDate=2018-04-28, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-28, endDate=2018-04-29, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-29, endDate=2018-04-30, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
RECURRING{startDate=2018-04-30, endDate=2018-05-01, amount=10.00, rate=10, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, linkedItemId=null}
DefaultBillingEvent{type=BCD_CHANGE, effectiveDate=2018-05-01T23:06:31.000Z, planPhaseName=plan_0fa66863-8819-406d-8d91-de2e8f1a6fa8-evergreen, subscriptionId=8e5d0be0-2d3c-4191-bf03-00fd03ed7109, totalOrdering=1665}

I had one more question - if we have sample request - POST http://killbill1/1.0/kb/invoices?accountId=5283458b-a2d7-49ce-8b63-e10eab6a5e8b&targetDate=2018-05-01 -- this is to generate the invoice. Trying to understand the logic around targetDate. Does the targetDate mean, create invoice for those subscriptions for which the SUBSCRIPTIONS.START_DATE is 2018-05-01?

Thanks for your time.

Suhasini.

[Pierre-Alexandre Meyer]

On Thu, Apr 12, 2018 at 6:20 PM, <suha...@poynt.co> wrote:

I created a plan with 'DAILY' billing period and subscribed to it and tried to generate the invoice. I see the following in the log file (which reflects daily subscription) .  Looks like DAILY is supported.

Yes, DAILY has been supported for a couple of years now (this mailing-list thread is older).

 

Could it be because we are using a older version of killbill (not sure what the latest version is)

The latest version of the community edition is 0.18.19.

I had one more question - if we have sample request -  POST http://killbill1/1.0/kb/invoices?accountId=5283458b-a2d7-49ce-8b63-e10eab6a5e8b&targetDate=2018-05-01   -- this is to generate the invoice. Trying to understand the logic around targetDate. Does the targetDate mean, create invoice for those subscriptions for which the SUBSCRIPTIONS.START_DATE is 2018-05-01?

We call targetDate the date up to which we want the invoicing system to bill.

See http://docs.killbill.io/latest/invoice_subsystem.html#_overview. 

Hope that helps,

--

Pierre

[Suhasini Goli]

Thanks so much Pierre.

Best Regards,

Suhasini