We are looking to implement a system in which users can load a balance onto their account, spend it down via metered use, and then top off their balance when it is low. I believe in previous threads this model has been referred to as consumable in advance.
We have consumable in arrear workflow working using the features built in to killbill. Has there been any work done on the prepaid model?
Currently our thought for implementation is:
a. When a user wants to top off their account, initiate a payment using the direct payment API. If successful, post a credit to the account in the same amount (POST /credits).
b. Turn off account auto-invoicing and auto-billing. At the start of each month, create a new invoice for the user using (POST /invoices). As usage occurs, create an external charge for each item (POST /invoices/charges). At the end of the month, trigger a payment for any remaining balance if there is one.
c. Our understanding is that account CBA is the current credit on the account minus any outstanding invoices, so with the two above in place, we should be able to monitor CBA for current balance while the invoice is still open. If below a threshold, we can initiate a new payment. If it hits zero, we can suspend the account until this is fixed.
We had the following questions:
1. Can you offer any input on our overall approach?
2. Is there any api call that both processes the payment and increases the credit? i.e. similar to what payAllInvoices does for external payments in excess of existing invoices, but actually triggering the payment as well.
3. Even with AUTO_PAY_OFF, if there is credit on the account, it will be applied as soon as line items are added to an invoice. Is it possible to delay this until we actually trigger a payment on the invoice?
4. Is there a way to close an invoice to future changes? Once the invoice is closed out, we want to prevent any further external charges from being applied to it.
5. Another problem we have run into is small invoices. For consumable in appear, our users can sometimes end up with a bill under $0.50 on a given month. Stripe will not process such a payment, so the invoice payment fails. Even when a number of these invoices accrue, the payAllInvoices function tries to pay each individually rather than doing one payment for the full outstanding balance so they continue to fail. Is there a way around this issue?
Thank you for any guidance you can offer.
--
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/75fa6c15-1cdc-4546-946f-2b18b2e95c1c%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
When we try to call @kb_apis.payment_api.create_purchase, we get an error. The context works fine for the other @kb_apis calls being done.
One thing I noticed when searching for the login call is that most of the api methods are wrapped in https://github.com/killbill/killbill-plugin-framework-ruby/tree/master/lib/killbill/gen/api but security_api does not have such a file.
Thank you, for now we have went ahead and used the ruby client within the plugin. The payment, credit, and adjustment calls are all working for us.
Atomicity would be nice, but I imagine assume this cannot be accomplished using the plugin system.