Invoice cancelation/deferring invoice creation after payment has been succesfully captured

[David Concha]

Hi there, we're using KB to process invoices for web services that are made immediately available to users. In our world if we can not process the payment right after the user confirms the purchase it doesn't makes sense to process the payment later (the user is gone from the site and most likely he won't come back to make the same purchase, if we just process the payment the most likely scenario is the user asking for a refund or even worst a chargeback).

So this was our original plan:

1-User enters payment method information
2-KB validates the PM
3-We create an invoice in KB
4-We let KB do it's thing and capture the payment
5-We provide the user with access.

The problem with this approach is that it is common that #4 will fail for things like insufficient funds or gateway communication or any number of different things. If this is the case we would need to cancel/write off the invoice so that if the user comes back and wants to make a different purchase we can process it without KB doing his thing and collecting the pending balance from the first invoice.

Since the former approach is no good for us we then tried to do the following instead:
1-User enters payment method information
2-KB validates the PM
3-we create a payment and let KB to capture it
4-we create the invoice
5-We provide the user with access.

By doing so it is possible to avoid the invoice creation if the payment can not be captured. However even when the account balance may be right there won't be any linking between the payment and the invoice(there won't be an InvoicePayment) and a lot of information gets lost. So with this approach we don't have the problem of having state invoices that are processed when we don't want them anymore but we now lack some relevant information.

So our question is: what would be the best way of handling this scenario?

[stephane brossier]

Hi David,

On Wed, Jan 27, 2016 at 4:31 PM, David Concha <dco...@rocketlawyer.com> wrote:

Hi there, we're using KB to process invoices for web services that are made immediately available to users. In our world if we can not process the payment right after the user confirms the purchase it doesn't makes sense to process the payment later (the user is gone from the site and most likely he won't come back to make the same purchase, if we just process the payment the most likely scenario is the user asking for a refund or even worst a chargeback).

So this was our original plan:

1-User enters payment method information
2-KB validates the PM
3-We create an invoice in KB
4-We let KB do it's thing and capture the payment
5-We provide the user with access.

The problem with this approach is that it is common that #4 will fail for things like insufficient funds or gateway communication or any number of different things.

Just to clarify: Step 3 and 4 are not separate in the sense that there was *ONE* api call (to create a new subscription or to add an external charge, both of which resulting in i/ the creation of an invoice, and then ii/ a payment for that matching invoice. 

 

If this is the case we would need to cancel/write off the invoice so that if the user comes back and wants to make a different purchase we can process it without KB doing his thing and collecting the pending balance from the first invoice.

I am not following that part: If the payment previously fail and "the user comes back and wants to make a different purchase" what does it have to do with the previous purchase that failed? If the user comes back and wants to make a different purchase, we go again through the steps you described and KB will not try to collect the pending balance from the first invoice. The two are completely independent.

Also note that there is already some support to write off an invoice if this is what you want to do (i believed we recently fixed that after you guys asked for it).

 

Since the former approach is no good for us we then tried to do the following instead:
1-User enters payment method information
2-KB validates the PM
3-we create a payment and let KB to capture it
4-we create the invoice
5-We provide the user with access.

I did not quite understand why the previous flow does not work for you, but commenting on what you are describing here: Now it looks like you are using the raw payment apis. This is certainly a possibility but i am not sure how that helps you with your use case: If the payment failed (e.g Insufficient fund) with the previous flow, it will still fail with that flow.  

 

By doing so it is possible to avoid the invoice creation if the payment can not be captured. However even when the account balance may be right there won't be any linking between the payment and the invoice(there won't be an InvoicePayment) and a lot of information gets lost. So with this approach we don't have the problem of having state invoices that are processed when we don't want them anymore but we now lack some relevant information.

So our question is: what would be the best way of handling this scenario?

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 https://groups.google.com/group/killbilling-users.
To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/ff2b33ce-36f6-43ff-84b4-97596e49eb98%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[David Concha]

Thanks for your quick reply Stephane. We have in fact looked into the possibility of writting off the invoice, also the possibility of adjusting the invoice items, we're not proposing anything here , we're just looking for your input around the best way of handling this. At this point the easiest route from our perspective is to write off the invoice but that would leave us with a lot of written off invoices. We think in some ways triggering the raw payment, and then creating the invoice and linking the payment to it would be a better way to go but again we don't feel strongly about it and we're completely open for suggestions.

Comments in line:

On Wed, Jan 27, 2016 at 8:38 PM, stephane brossier <step...@kill-bill.org> wrote:

Hi David,

On Wed, Jan 27, 2016 at 4:31 PM, David Concha <dco...@rocketlawyer.com> wrote:

Hi there, we're using KB to process invoices for web services that are made immediately available to users. In our world if we can not process the payment right after the user confirms the purchase it doesn't makes sense to process the payment later (the user is gone from the site and most likely he won't come back to make the same purchase, if we just process the payment the most likely scenario is the user asking for a refund or even worst a chargeback).

So this was our original plan:

1-User enters payment method information
2-KB validates the PM
3-We create an invoice in KB
4-We let KB do it's thing and capture the payment
5-We provide the user with access.

The problem with this approach is that it is common that #4 will fail for things like insufficient funds or gateway communication or any number of different things.

Just to clarify: Step 3 and 4 are not separate in the sense that there was *ONE* api call (to create a new subscription or to add an external charge, both of which resulting in i/ the creation of an invoice, and then ii/ a payment for that matching invoice. DC: Yes this is our understanding as well

 

If this is the case we would need to cancel/write off the invoice so that if the user comes back and wants to make a different purchase we can process it without KB doing his thing and collecting the pending balance from the first invoice.

I am not following that part: If the payment previously fail and "the user comes back and wants to make a different purchase" what does it have to do with the previous purchase that failed? If the user comes back and wants to make a different purchase, we go again through the steps you described and KB will not try to collect the pending balance from the first invoice. The two are completely independent. DC: Yes this is completely true but yet at this point the account balance is not right, and there is potential for other actions to make the payment system to collect the pending balance, and the overdue system will still considering that user as overdue which is not desired. In general the data in the system looks like the user owes some money(from the first purchase) but he in fact does not (the purchase was never completed) and this has a lot of implications. 

Also note that there is already some support to write off an invoice if this is what you want to do (i believed we recently fixed that after you guys asked for it).

 

Since the former approach is no good for us we then tried to do the following instead:
1-User enters payment method information
2-KB validates the PM
3-we create a payment and let KB to capture it
4-we create the invoice
5-We provide the user with access.

I did not quite understand why the previous flow does not work for you, but commenting on what you are describing here: Now it looks like you are using the raw payment apis. This is certainly a possibility but i am not sure how that helps you with your use case: If the payment failed (e.g Insufficient fund) with the previous flow, it will still fail with that flow.  DC: Balance on cards change all the time so it's possible that when the user comes back there's now sufficient funds, other possibility is that the user may provide a different payment method the second time or if the gateway was down the first time it may be up now. There's a lot of things that could change to make the second one go through after the initial failed attempt.  

 

By doing so it is possible to avoid the invoice creation if the payment can not be captured. However even when the account balance may be right there won't be any linking between the payment and the invoice(there won't be an InvoicePayment) and a lot of information gets lost. So with this approach we don't have the problem of having state invoices that are processed when we don't want them anymore but we now lack some relevant information. DC Would it be as simple as creating the invoicePayment through a new API?

So our question is: what would be the best way of handling this scenario?

[stephane brossier]

David,

I think i am starting to understand a bit better what your scenario is and what you want. The first remark is that in many ways the scenario you are describing is a common one (a user pays for a service but payment fails and he goes away); what makes your story slightly different is that, that same user may come back in the future and you would like i/ him to not be 'impacted' by that previous action and ii/ even make that previous action hidden for the rest of the company (accounting/finance). Basically as if it had not happen.

You also correctly identified two possible paths:

1. You rely on Kill Bill subscription/invoicing system and then invoices will get created

2. You don't rely on Kill Bill subscription/invoicing system and but then you have no state

I would suggest you don't go with second path because otherwise i/ you remove lots of value from using the system and ii/ recreating some state by hacking invoice_payments table will certainly not work (for one thing you would have no invoice, and each time we make changes in the system we may break your stuff).

The typical way of handling that common scenario is to cancel the subscription at the start of term (i am guessing you created a subscription, which created the invoice on which the payment failed) . By doing so, the 'entitlement' attached to that subscription is cancelled (and therefore user does not benefit from using the service) and the invoice gets repaired in such a way that balance automatically goes back to $0, and user is back in a good state. This is the correct way to handle that scenario. It still leaves you with $0 invoices but in all fairness those do exist, and do correspond to something that actually happened, so i am not sure what the issue really is if the user gets to see such invoices, or if your accounting team sees them. They are real, things happened.

If you really need to hide such invoices for users and/or accounting/finance, you can tag them in such a way that they become easy to be left out:

* You could implement a small plugin that exports an endpoint to return invoices and filters the one that were tagged (instead of calling regular /1.0/kb/invoices KB endpoint you would call your plugin endpoint)

* If you need to look at data directly you can join tables to eliminate the one with that tag.

Hope that helps,

Stéphane

[stephane brossier]

David,

I am curious about which direction you chose. Did you try the cancellation at start of term? If not, what did you decide on?

Thanks,

Stéphane

[Roberto Vallejo]

Hi Stéphane,

We decided to go with writing off the invoices when the payment fails.

Thanks.

--

Roberto

[David Concha]

Hi there,

In case of subscriptions we also cancel them so we don't get any additional invoices

--

David Concha | Engineering Manager 

Rocket Lawyer is the affordable and simple legal service for everyone. Our legal documents are free, and our Rocket Lawyer On Call® legal plans give businesses, families and individuals discounted access to licensed attorneys, plus a whole lot more.  Since Rocket Lawyer is not a law firm, we don't provide legal advice. We deliver the legal services you need at a price you'll love.

[being...@gmail.com]

How did you did write off?

[stephane brossier]

See api reference here.

On Thu, Aug 2, 2018 at 1:20 AM, <being...@gmail.com> wrote:

How did you did write off?

--
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-users+unsubscribe@googlegroups.com.
To post to this group, send email to killbilling-users@googlegroups.com.

Visit this group at https://groups.google.com/group/killbilling-users.

To view this discussion on the web visit https://groups.google.com/d/msgid/killbilling-users/89b37b0c-e8bd-4080-aeb7-d8c47c1d534c%40googlegroups.com.