Hi All,
I have an issue and a question.
The case:
Our plans are all prepaid plans, and to ensure that when we create a subscription we charge the account, we make sure the entitlementDate and billingDate are equal NOW.It turns out that for any reason, sometimes Killbill is delaying the invoice generation, and consequently does not charge the account when the subscription is created. I believe this could be related to some internal processing queue, because most of the time the invoice and charge are generated as soon as the subscription is created.
Given:
- AUTO_INVOICING_DRAFT is FALSE for all accounts (invoice is committed automatically)
- When creating the subscription we send callCompletion as TRUE and callTimeoutSec as 60 (seconds)- We're using recurring payment for the subscription, not one-time payments
My questions are:
- Do you have any suggestions on how to to check the reason why Killbill often doesn't generate the invoice as soon as the the subscription is added?
- Is there any way to only allow a subscription to be added if the invoice is generated and the charge is made?
I already tried the following solutions:
- After adding the subscription, I check if there is any payment pending for the generated invoice (since the invoice is generated). If there is a pendimgn payment, I trigger the payment for the invoice through the API POST /1.0/kb/invoices/{invoiceId}/payments
- If a payment fails for any reason, I cancel the subscription. The problem is that sometimes the invoice is not generated (as explained above), so there is no pending payment to be triggered in that case.
- To ensure that the invoice will be generated (when the invoice is NOT automatically generated after the subscription is added), I call the POST API
/1.0/kb/invoices to trigger the invoice generation. The problem is that this API takes a few seconds longer to create the invoice and process the payment, and this causes a bad experience for the user once the request takes longer than necessary
Any tips?
Thank you in advance,
Rodrigo
Hi All,
I have an issue and a question.
The case:
Our plans are all prepaid plans, and to ensure that when we create a subscription we charge the account, we make sure the entitlementDate and billingDate are equal NOW.It turns out that for any reason, sometimes Killbill is delaying the invoice generation, and consequently does not charge the account when the subscription is created. I believe this could be related to some internal processing queue, because most of the time the invoice and charge are generated as soon as the subscription is created.
Given:
- AUTO_INVOICING_DRAFT is FALSE for all accounts (invoice is committed automatically)
- When creating the subscription we send callCompletion as TRUE and callTimeoutSec as 60 (seconds)- We're using recurring payment for the subscription, not one-time payments
My questions are:
- Do you have any suggestions on how to to check the reason why Killbill often doesn't generate the invoice as soon as the the subscription is added?
- Is there any way to only allow a subscription to be added if the invoice is generated and the charge is made?
I already tried the following solutions:
- After adding the subscription, I check if there is any payment pending for the generated invoice (since the invoice is generated). If there is a pendimgn payment, I trigger the payment for the invoice through the API POST /1.0/kb/invoices/{invoiceId}/payments
- If a payment fails for any reason, I cancel the subscription. The problem is that sometimes the invoice is not generated (as explained above), so there is no pending payment to be triggered in that case.
- To ensure that the invoice will be generated (when the invoice is NOT automatically generated after the subscription is added), I call the POST API
/1.0/kb/invoices to trigger the invoice generation. The problem is that this API takes a few seconds longer to create the invoice and process the payment, and this causes a bad experience for the user once the request takes longer than necessary
Any tips?
Thank you in advance,
Rodrigo
--
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 view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/664470ef-a31d-41c0-82bd-0ed8220a23d2n%40googlegroups.com.
Hi Karan and Shaun,
Karan, I didn't notice a specific moment or reason where the problem happens. I've seen it happen even on days of low access to our applications. Seems a bit random to me. Our customers can create subscriptions any day of the month, so we don't have a bulk subscription processing day for example. When it comes to the properties, we use the default settings, we don't overwrite any properties. Related to plugins, we only use the Stripe plugin to charge the subscriptions. We don't have any other plugins and the Stripe plugin doesn't intercept invoice generation (as far as I know).
Looking at logs I don't see any errors or warnings. The only thing that I noticed, is that the killbill.notifications table contains a lot of records with classname 'org.killbill.billing.invoice.notification.NextBillingDateNotificationKey' in status 'AVAILABLE' and queue as 'invoice-service:next-billing -date-queue'. Do you think this could indicate a problem? Is there any documentation that I can refer to on how each notification should be processed?
Shaun, all of our plans are set up with the recurringBillingMode as IN_ADVANCE, and whenever a plan is created, we make sure that the entitlementDate and billingDate values are passed with the current date/time. This way, except in the case of the failure that I described, the invoice is always generated just after the plan is created, and consequently the charge is made. Around 500 subscriptions are created per month, and in most of the cases, the invoice is generated immediately after creating the subscription.
Sirs, as far as I could understand, in the current Killbill architecture there is no guarantee that a subscription will only be added if the payment is approved. Am I correct in thinking this?
I think an alternative would be to process a one-time payment. If approved, generate a credit to the account and then add the subscription. That way the first charge would use the account credit instead of charging the payment method and I would ensure the subscription was paid before being added.
In your experience, does this solution make sense? Do you know other use cases of platforms that also need to guarantee the payment of the first invoice before adding the subscription? How have other customers solved this use case? Let's take Spotify as an example. We only join the plan if the payment is confirmed. Both cases make sense to me, in different contexts, of course.
Thank you in advance for your considerations,
Rodrigo
--Rodrigo Zanel