Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ability to override paymentMethod per subscription/bundle #277

Open
sbrossie opened this issue Feb 25, 2015 · 2 comments
Open

Ability to override paymentMethod per subscription/bundle #277

sbrossie opened this issue Feb 25, 2015 · 2 comments

Comments

@sbrossie
Copy link
Member

@sbrossie sbrossie commented Feb 25, 2015

Today, when an invoice needs to be paid, the payment code extracts the default payment method associated with the account. An invoice contains potentially several items, each of which can map to a specific bundle/subscription. A Payment matches a specific invoice. Associating a payment method with a specific subscription or bundle will only work if the invoice associated with the payment contains only one subscription/bundle (or they all share the same overridden payment method).

Fortunately we have a mechanism in catalog to group certain subscription/bundle into one invoice. This is called billingAlignment, and we support 3 cases:

  • ACCOUNT (all subscriptions will appear on one invoice)

  • BUNDLE (all subscriptions for a given bundle will appear on one invoice)

  • SUBSCRIPTION (only a specific subscription will appear on one given invoice)

    In order to override that behavior and override payment method per subscription/bundle, there are several possible designs:

  1. Extend the current InvoicePaymentRoutingPluginApi to implement that functionality. The InvoicePaymentRoutingPluginApi implements the PaymentRoutingPluginApi, and that api is called from RetryOperationCallback to potentially break the flow or override values such as amount to be paid, currency to use, but also payment method that should be be used.

So, that code could be extended in the following way:

  • Add a new table (state) to capture the paymentMethodId associated to a given bundle/subscription
  • Export a new endpoint to register the paymentMethodId associated to a given bundle/subscription
  • Have the InvoicePaymentRoutingPluginApi check whether the payment method should be overridden by looking in the new table.

The issue is that this code (InvoicePaymentRoutingPluginApi) has not been extracted as a first class citizen plugin and is still part of Kill Bill core.

  1. Modification of the previous proposal but in a custom plugin

The system property org.killbill.payment.invoice.plugin allows to specify an order of PaymentRoutingPluginApi that will be called by RetryOperationCallback in the priorCall method.
This one will now need to contain "INVOICE_PAYMENT_CONTROL_PLUGIN, <name_of_new_plugin>", in that order.

The invoiceId that will be needed can be extracted using the property PROP_IPCD_INVOICE_ID. See for instance how this is done in InvoicePaymentRoutingPluginApi:
final PluginProperty invoiceProp = getPluginProperty(paymentRoutingContext.getPluginProperties(), PROP_IPCD_INVOICE_ID);

@chris13524

This comment has been minimized.

Copy link

@chris13524 chris13524 commented Jun 29, 2017

Any news on this? This would be a great feature to have.

@pierre

This comment has been minimized.

Copy link
Member

@pierre pierre commented Jun 30, 2017

@chris13524 This is currently not on our radar, as we haven't seen a strong demand for it. If you are interested in contributing, feel free to reach out to our mailing-list. It's a large change though, so it would land in 0.20.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
3 participants
You can’t perform that action at this time.