Invoice payment error when creating subsciption with no payment method

[nand...@womply.com]

Hello,

We are encountering problems when creating subscriptions on an account with no payment method. Locally my call to javaclient.createSubscription() or createSubscriptionWithAddons() with a single subscription times out and I can see an INVOICE_PAYMENT_ERROR in the kill bill log. Strangely, calling createSubsctiptionWithAddons() with a base subscription and add-on produces the same error in the log but returns successfully even with a non-zero timeout. If I run the same operations against our preprod server I do not see the INVOICE_PAYMENT_ERROR but I see this exception instead:

java.sql.SQLIntegrityConstraintViolationException: Column 'payment_method_id' cannot be null [statement:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", located:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", rewritten:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", arguments:{ positional:{0:'7321663f-
8193-4b65-9004-af4fd992a581',1:'229fa2f1-d958-49cd-9595-512786e6b915',2:'4d080070-74bb-41fc-a9e3-b71182980a1d',3:UUIDArgument{value=8227aaa4-c535-4357-ab94-ec4a6cafac90},4:'__INVOICE_PAYMENT_CONTROL_PLUGIN__',5:null,6:null,7:1.00,8:USD,9:'InvoicePaymentControlPluginApi',10:DateTimeArgument{value=2016-08-27T01:32:33.000Z}}, named:{}, finder:[]}]'}

This exception does not appear in the case of creating a subscription with an add-on. Also, I am unable to replicate this stacktrace locally and placing a breakpoint in the method where I am assuming it is generated (insert_AUTO_PAY_OFF_ifRequired() in InvoicePaymentControlPluginApi.java) has not yielded results. The breakpoint trips in that method but returns false before it can attempt to insert into the _invoice_payment_control_plugin_auto_pay_off table.

I was under the impression that the auto pay off account tag would stop payment attempts so I'm not sure why I am getting an invoice payment error. I would expect that a subscription created on an account without a payment method would generate an invoice but not try to pay it off. The server-side stacktrace looks to be related to the auto pay off tag but I am not familiar enough with the code to see how the _invoice_payment_control_plugin_auto_pay_off table is used.

This seems like it could be a combination of issues. There is my potentially incorrect reasoning about the auto pay off tag, the fact that the problem changes depending on whether a base subscription is created or a base with an add-on, and that it behaves differently in the two environments I have tested it in. Should I just never try to create a subscription on an account with no current way to pay? Or is there one or two bugs at work?

Thanks,
Nate Anderson

[stephane brossier]

On Fri, Sep 9, 2016 at 3:09 PM, <nand...@womply.com> wrote:

Hello,

We are encountering problems when creating subscriptions on an account with no payment method.

Which version of KB? Is that 0.16.8?

 

Locally my call to javaclient.createSubscription() or createSubscriptionWithAddons() with a single subscription times out and I can see an INVOICE_PAYMENT_ERROR in the kill bill log. Strangely, calling createSubsctiptionWithAddons() with a base subscription and add-on produces the same error in the log but returns successfully even with a non-zero timeout. If I run the same operations against our preprod server I do not see the INVOICE_PAYMENT_ERROR but I see this exception instead:

Which version of the client are you using? Are you setting query param 'callCompletion=true' ?

 

java.sql.SQLIntegrityConstraintViolationException: Column 'payment_method_id' cannot be null [statement:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", located:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", rewritten:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", arguments:{ positional:{0:'7321663f-
8193-4b65-9004-af4fd992a581',1:'229fa2f1-d958-49cd-9595-512786e6b915',2:'4d080070-74bb-41fc-a9e3-b71182980a1d',3:UUIDArgument{value=8227aaa4-c535-4357-ab94-ec4a6cafac90},4:'__INVOICE_PAYMENT_CONTROL_PLUGIN__',5:null,6:null,7:1.00,8:USD,9:'InvoicePaymentControlPluginApi',10:DateTimeArgument{value=2016-08-27T01:32:33.000Z}}, named:{}, finder:[]}]'}

Ideally this check should happen prior we hit the DB (and get that exception), but that aside, the constraint violation exception makes sense.

 

This exception does not appear in the case of creating a subscription with an add-on.

Interesting. And what do you get there?

 

Also, I am unable to replicate this stacktrace locally and placing a breakpoint in the method where I am assuming it is generated (insert_AUTO_PAY_OFF_ifRequired() in InvoicePaymentControlPluginApi.java) has not yielded results. The breakpoint trips in that method but returns false before it can attempt to insert into the _invoice_payment_control_plugin_auto_pay_off table.

Unfortunate. Not sure how we can help with that though.

 

I was under the impression that the auto pay off account tag would stop payment attempts so I'm not sure why I am getting an invoice payment error.

Yes, AUTO_PAY_OFF will prevent any payment to happen (at least this is the idea) 

 

I would expect that a subscription created on an account without a payment method would generate an invoice but not try to pay it off.

Assuming you have AUTO_PAY_OFF set at the account level, this is correct.

 

The server-side stacktrace looks to be related to the auto pay off tag but I am not familiar enough with the code to see how the _invoice_payment_control_plugin_auto_pay_off table is used.

This seems like it could be a combination of issues. There is my potentially incorrect reasoning about the auto pay off tag, the fact that the problem changes depending on whether a base subscription is created or a base with an add-on, and that it behaves differently in the two environments I have tested it in. Should I just never try to create a subscription on an account with no current way to pay? Or is there one or two bugs at work?

Could we step back, and could you describe exactly what you are trying to do (precise steps for your scenario) so we have a chance to follow what is going?

Stéphane

Thanks,
Nate Anderson

--
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/2facfca1-f60c-4271-8844-b3a42d2c7aa3%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[nand...@womply.com]

Hi Stéphane,

The basic thing I am trying to do is to add a base subscription or a base and add-on to an account that doesn't have a payment method but does have the auto pay off tag. The subscriptions all have recurring costs. If I do this against a local KB it seems to work correctly, but if I do it against a local KB in a docker container the call fails in the case of the base only subscription and in both cases I see the SQLIntegrityConstraintViolationException that I noted in the first message.

I think I am seeing two bugs. One is the call timing out when creating a base subscription alone vs creating a base and add-on in a single call. This can be replicated by creating the subscriptions on an account with no payment method and no auto pay off tag. Both cases result in an INVOICE_PAYMENT_ERROR but only the base with no add-on call will correctly time out. (My INVOICE_PAYMENT_ERROR problems in the first post were caused by my lack of an auto pay off tag).

The second bug is the SQLIntegrityConstraintViolationException and I have only been able to make it happen on a Kill Bill instance running in a docker container. I am currently trying to create a simple test case for this to eliminate the possibility that the problem is a custom plugin that we wrote or something of that nature. Creating subscriptions on an account with no payment method and with an auto pay off tag triggers this problem. The subscription is created successfully and, if created with an add-on, the method returns correctly, so it is potentially only visible in the logs.

I'll keep working on an easier way to reproduce the problem. Please let me know if you need more information.

Thanks,
Nate

[stephane brossier]

Hi Nate,

On Wed, Sep 14, 2016 at 4:25 PM, <nand...@womply.com> wrote:

Hi Stéphane,

The basic thing I am trying to do is to add a base subscription or a base and add-on to an account that doesn't have a payment method but does have the auto pay off tag. The subscriptions all have recurring costs. If I do this against a local KB it seems to work correctly, but if I do it against a local KB in a docker container the call fails in the case of the base only subscription and in both cases I see the SQLIntegrityConstraintViolationException that I noted in the first message.

If the call works locally and fails in docker i suspect this is a setup issue (maybe your are using a different KB version, or your DB schema is different,...). I can't think of any other reason why with an exact same config such call would work locally and not in docker. 

By the way i asked you previously about the version you are using (please always include such info, our code changes quite a bit across version, so we need to know where to look).

 

Just to confirm your (basic) scenario:

1. Create account

2. set AUTO_PAY_OFF

3. Create a subscription => system generates an invoice

4 ISSUE: Payment system attempts to make a payment (although AUTO_PAY_OFF is set) and as a result you see INVOICE_PAYMENT_ERROR

I think I am seeing two bugs. One is the call timing out when creating a base subscription alone vs creating a base and add-on in a single call. This can be replicated by creating the subscriptions on an account with no payment method and no auto pay off tag. Both cases result in an INVOICE_PAYMENT_ERROR but only the base with no add-on call will correctly time out. (My INVOICE_PAYMENT_ERROR problems in the first post were caused by my lack of an auto pay off tag).

The second bug is the SQLIntegrityConstraintViolationException and I have only been able to make it happen on a Kill Bill instance running in a docker container. I am currently trying to create a simple test case for this to eliminate the possibility that the problem is a custom plugin that we wrote or something of that nature. Creating subscriptions on an account with no payment method and with an auto pay off tag triggers this problem. The subscription is created successfully and, if created with an add-on, the method returns correctly, so it is potentially only visible in the logs.

When you see the SQLIntegrityConstraintViolationException, does it indicate which table, which index (and for which query?)

 

I'll keep working on an easier way to reproduce the problem.

That would be great (unless you provide info about how to reproduce such scenario this is a bit abstract).

 

Thanks,

Stéphane

Please let me know if you need more information.

Thanks,
Nate

--
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/1ce0b8fb-629f-45df-9f41-740444f6ae6c%40googlegroups.com.

[stephane brossier]

Nate,

Circling back on that issue: Did you come to a resolution?

Stéphane

[nand...@womply.com]

Stéphane,

Sorry, I have had other work and haven't been able to look into this for a few days. I hope to try and replicate the SQLIntegrityConstraintViolationException in a simpler test case by the end of the week.

We are currently running KB 0.16.8.

The steps to reproduce the lack of timeout on error when creating a base + add-on subscription are:
1. Create two plans in the catalog, one base and one add-on, both requiring a payment.
2. Create an account with no payment method.
3. Make sure the account does NOT have AUTO_PAY_OFF. This is an easy way to cause an error when creating a subscription that requires a payment.
4. Create a subscription and add-on using createSubscriptionWithAddons with callCompletion=true and a timeout.

The call returns without expiring the timeout even though there is an internal error caused by a payment attempt with no payment method.

Creating a subscription of the base plan alone with the same timeout parameters will return with an error after the timeout expires. I am assuming that this is the correct behavior.

I will get back to you on the SQLIntegrityConstraintViolationException when I have time to nail it down and make sure it isn't a problem on our end.

Thanks,
Nate

[stephane brossier]

Nate,

Starting to look into your issue; i have a question:

On Wed, Sep 21, 2016 at 2:39 PM, <nand...@womply.com> wrote:

Stéphane,

Sorry, I have had other work and haven't been able to look into this for a few days. I hope to try and replicate the SQLIntegrityConstraintViolationException in a simpler test case by the end of the week.

We are currently running KB 0.16.8.

The steps to reproduce the lack of timeout on error when creating a base + add-on subscription are:
1. Create two plans in the catalog, one base and one add-on, both requiring a payment.
2. Create an account with no payment method.
3. Make sure the account does NOT have AUTO_PAY_OFF. This is an easy way to cause an error when creating a subscription that requires a payment. 

4. Create a subscription and add-on using createSubscriptionWithAddons with callCompletion=true and a timeout.

The call returns without expiring the timeout even though there is an internal error caused by a payment attempt with no payment method.

 Let's first agree, on what we expect to see: In the scenario where 'callCompletion=true and a timeout is set' and you get an error, i would expect the call to return right away (as soon as error arise, and not hitting the timeout). The timeout is just there for cases where things take too long. So I am confused about your statement: "The call returns without expiring the timeout even though there is an internal error"

Do you expect the call to time-out?

 

Creating a subscription of the base plan alone with the same timeout parameters will return with an error after the timeout expires. I am assuming that this is the correct behavior.

I will get back to you on the SQLIntegrityConstraintViolationException when I have time to nail it down and make sure it isn't a problem on our end.

Thanks,
Nate

--
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/9df9ee2b-aee4-4bf6-8963-8207e0309587%40googlegroups.com.

[stephane brossier]

Nate,

FYI, I created issue #622 to track the work. Let us know when you have more details. No rush on our side.

S.

[gpre...@womply.com]

I'm not sure if this is exactly the same issue, but I was able to get a similar error when trying to create a subscription on an account that had had two payment methods, and then the default one was deleted. If I delete the non-default payment method instead, it goes through just fine.



2017-01-12T20:21:34,629+0000 lvl='INFO', log='LoggingFilter', th='catalina-exec-4', xff='', rId='65d1ead2-25cd-46ac-b190-05ca22be9260', aRId='', tRId='1', 149 * Server in-bound request
149 > POST http://kb:8080/1.0/kb/subscriptions?callCompletion=true&callTimeoutSec=30&requestedDate=2017-01-12T20%3A21%3A34.333Z
149 > accept: application/json
149 > content-type: application/json; charset=utf-8
149 > x-killbill-apikey: billing-v1
149 > x-killbill-apisecret: womply16
149 > x-killbill-createdby: 585334
149 > x-killbill-reason: test reason
149 > x-killbill-comment: test comment
149 > content-length: 442
149 > connection: keep-alive
149 > host: kb:8080
149 > authorization: Basic YWRtaW46cGFzc3dvcmQ=
149 > user-agent: KillBill-JavaClient/1.0
149 >

2017-01-12T20:21:34,737+0000 lvl='INFO', log='BillCycleDayCalculator', th='bus_events-th', xff='', rId='', aRId='4', tRId='1', Calculated BCD: subscriptionId='ba6cb271-0d03-47ff-ab58-c6bbe5153e2b', subscriptionStartDate='2017-02-12T20:21:34.000Z', accountTimeZone='UTC', bcd='12'
2017-01-12T20:21:34,779+0000 lvl='INFO', log='KillbillLogWriter', th='Thread-11', xff='', rId='', aRId='3', tRId='1', [org.killbill.killbill.osgi.libs.killbill.OSGIKillbillServiceReference@42ccb70f]Received event SUBSCRIPTION_CREATION for object id ba6cb271-0d03-47ff-ab58-c6bbe5153e2b of type SUBSCRIPTION for account a946d1b0-57bc-48a3-bfb1-39598754c4a1
2017-01-12T20:21:34,821+0000 lvl='INFO', log='BillCycleDayCalculator', th='bus_events-th', xff='', rId='', aRId='4', tRId='1', Calculated BCD: subscriptionId='ba6cb271-0d03-47ff-ab58-c6bbe5153e2b', subscriptionStartDate='2017-02-12T20:21:34.000Z', accountTimeZone='UTC', bcd='12'
2017-01-12T20:21:34,827+0000 lvl='INFO', log='DefaultInternalBillingApi', th='bus_events-th', xff='', rId='', aRId='4', tRId='1', Computed billing events for accountId='a946d1b0-57bc-48a3-bfb1-39598754c4a1'
Billing Events Raw
DefaultBillingEvent{type=CREATE, effectiveDate=2017-01-12T20:21:34.000Z, planPhaseName=customerfeedback-standalone-monthly-trial, subscriptionId=ba6cb271-0d03-47ff-ab58-c6bbe5153e2b, totalOrdering=13}
DefaultBillingEvent{type=PHASE, effectiveDate=2017-02-12T20:21:34.000Z, planPhaseName=customerfeedback-standalone-monthly-evergreen, subscriptionId=ba6cb271-0d03-47ff-ab58-c6bbe5153e2b, totalOrdering=14}
Billing Events After Blocking
DefaultBillingEvent{type=CREATE, effectiveDate=2017-01-12T20:21:34.000Z, planPhaseName=customerfeedback-standalone-monthly-trial, subscriptionId=ba6cb271-0d03-47ff-ab58-c6bbe5153e2b, totalOrdering=13}
DefaultBillingEvent{type=PHASE, effectiveDate=2017-02-12T20:21:34.000Z, planPhaseName=customerfeedback-standalone-monthly-evergreen, subscriptionId=ba6cb271-0d03-47ff-ab58-c6bbe5153e2b, totalOrdering=14}
2017-01-12T20:21:34,830+0000 lvl='INFO', log='FixedAndRecurringInvoiceItemGenerator', th='bus_events-th', xff='', rId='', aRId='4', tRId='1', Proposed Invoice items for invoiceId='0163096c-5c1f-48c4-bd8d-4d31ffe3602b', accountId='a946d1b0-57bc-48a3-bfb1-39598754c4a1'
DefaultBillingEvent{type=CREATE, effectiveDate=2017-01-12T20:21:34.000Z, planPhaseName=customerfeedback-standalone-monthly-trial, subscriptionId=ba6cb271-0d03-47ff-ab58-c6bbe5153e2b, totalOrdering=13}
DefaultBillingEvent{type=PHASE, effectiveDate=2017-02-12T20:21:34.000Z, planPhaseName=customerfeedback-standalone-monthly-evergreen, subscriptionId=ba6cb271-0d03-47ff-ab58-c6bbe5153e2b, totalOrdering=14}
2017-01-12T20:21:34,834+0000 lvl='INFO', log='InvoiceDispatcher', th='bus_events-th', xff='', rId='', aRId='4', tRId='1', Generated invoiceId='0163096c-5c1f-48c4-bd8d-4d31ffe3602b', numberOfItems='1', accountId='a946d1b0-57bc-48a3-bfb1-39598754c4a1', targetDate='2017-01-12':
item = FIXED{startDate=2017-01-12, endDate=null, amount=1.00, rate=null, subscriptionId=ba6cb271-0d03-47ff-ab58-c6bbe5153e2b, linkedItemId=null}

2017-01-12T20:21:34,905+0000 lvl='INFO', log='KillbillLogWriter', th='Thread-11', xff='', rId='', aRId='3', tRId='1', [org.killbill.killbill.osgi.libs.killbill.OSGIKillbillServiceReference@3331a7f6]Received event ACCOUNT_CHANGE for object id a946d1b0-57bc-48a3-bfb1-39598754c4a1 of type ACCOUNT for account a946d1b0-57bc-48a3-bfb1-39598754c4a1
2017-01-12T20:21:35,030+0000 lvl='INFO', log='PaymentBusEventHandler', th='bus_events-th', xff='', rId='', aRId='4', tRId='1', Received invoice creation notification for accountId='a946d1b0-57bc-48a3-bfb1-39598754c4a1', invoiceId='0163096c-5c1f-48c4-bd8d-4d31ffe3602b'
2017-01-12T20:21:35,079+0000 lvl='INFO', log='SubscriptionResource', th='bus_events-th', xff='', rId='', aRId='4', tRId='1', Got event SubscriptionBaseTransition token='65d1ead2-25cd-46ac-b190-05ca22be9260', type='CREATE', remaining='0'
2017-01-12T20:21:35,080+0000 lvl='INFO', log='KillbillLogWriter', th='Thread-11', xff='', rId='', aRId='3', tRId='1', [org.killbill.killbill.osgi.libs.killbill.OSGIKillbillServiceReference@29f50c01]Received event SUBSCRIPTION_CREATION for object id ba6cb271-0d03-47ff-ab58-c6bbe5153e2b of type SUBSCRIPTION for account a946d1b0-57bc-48a3-bfb1-39598754c4a1
2017-01-12T20:21:35,150+0000 lvl='WARN', log='OperationControlCallback', th='bus_events-th', xff='', rId='', aRId='4', tRId='1', Operation failed for accountId='W_85140' accountExternalKey='Internal payment error : org.skife.jdbi.v2.exceptions.CallbackFailedException: org.skife.jdbi.v2.exceptions.UnableToExecuteStatementException: java.sql.SQLIntegrityConstraintViolationException: Column 'payment_method_id' cannot be null [statement:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", located:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", rewritten:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", arguments:{ positional:{0:'fc4e4dfc-a05c-460f-b8dc-850dda3b1777',1:'dce1ecf0-7b75-46b7-ba67-1038d0cf2d94',2:'c835f47b-9901-4251-8826-52fc3f386842',3:UUIDArgument{value=a946d1b0-57bc-48a3-bfb1-39598754c4a1},4:'__INVOICE_PAYMENT_CONTROL_PLUGIN__',5:null,6:null,7:1.00,8:USD,9:'InvoicePaymentControlPluginApi',10:DateTimeArgument{value=2017-01-12T20:21:35.000Z}}, named:{}, finder:[]}]' error='{}'
2017-01-12T20:21:35,205+0000 lvl='WARN', log='PaymentBusEventHandler', th='bus_events-th', xff='', rId='', aRId='4', tRId='1', Failed to process invoice payment {cause=org.skife.jdbi.v2.exceptions.CallbackFailedException: org.skife.jdbi.v2.exceptions.UnableToExecuteStatementException: java.sql.SQLIntegrityConstraintViolationException: Column 'payment_method_id' cannot be null [statement:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", located:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", rewritten:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", arguments:{ positional:{0:'fc4e4dfc-a05c-460f-b8dc-850dda3b1777',1:'dce1ecf0-7b75-46b7-ba67-1038d0cf2d94',2:'c835f47b-9901-4251-8826-52fc3f386842',3:UUIDArgument{value=a946d1b0-57bc-48a3-bfb1-39598754c4a1},4:'__INVOICE_PAYMENT_CONTROL_PLUGIN__',5:null,6:null,7:1.00,8:USD,9:'InvoicePaymentControlPluginApi',10:DateTimeArgument{value=2017-01-12T20:21:35.000Z}}, named:{}, finder:[]}], code=7019, formattedMsg='Internal payment error : org.skife.jdbi.v2.exceptions.CallbackFailedException: org.skife.jdbi.v2.exceptions.UnableToExecuteStatementException: java.sql.SQLIntegrityConstraintViolationException: Column 'payment_method_id' cannot be null [statement:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", located:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", rewritten:"insert into _invoice_payment_control_plugin_auto_pay_off (attempt_id, payment_external_key, transaction_external_key, account_id, plugin_name, payment_id, payment_method_id, amount, currency, created_by, created_date) values (?,?,?,?,?,?,?,?,?,?,?)", arguments:{ positional:{0:'fc4e4dfc-a05c-460f-b8dc-850dda3b1777',1:'dce1ecf0-7b75-46b7-ba67-1038d0cf2d94',2:'c835f47b-9901-4251-8826-52fc3f386842',3:UUIDArgument{value=a946d1b0-57bc-48a3-bfb1-39598754c4a1},4:'__INVOICE_PAYMENT_CONTROL_PLUGIN__',5:null,6:null,7:1.00,8:USD,9:'InvoicePaymentControlPluginApi',10:DateTimeArgument{value=2017-01-12T20:21:35.000Z}}, named:{}, finder:[]}]'}
2017-01-12T20:21:35,288+0000 lvl='INFO', log='SubscriptionResource', th='bus_events-th', xff='', rId='', aRId='4', tRId='1', Got event InvoiceCreationNotification token='65d1ead2-25cd-46ac-b190-05ca22be9260'
2017-01-12T20:21:35,290+0000 lvl='INFO', log='KillbillLogWriter', th='Thread-11', xff='', rId='', aRId='4', tRId='1', [org.killbill.killbill.osgi.libs.killbill.OSGIKillbillServiceReference@233e6665]Received event INVOICE_CREATION for object type = INVOICE, id = 0163096c-5c1f-48c4-bd8d-4d31ffe3602b
2017-01-12T20:21:35,291+0000 lvl='INFO', log='KillbillLogWriter', th='Thread-11', xff='', rId='', aRId='4', tRId='1', [org.killbill.killbill.osgi.libs.killbill.OSGIKillbillServiceReference@46dc9c2]Received event INVOICE_CREATION for object id 0163096c-5c1f-48c4-bd8d-4d31ffe3602b of type INVOICE for account a946d1b0-57bc-48a3-bfb1-39598754c4a1
2017-01-12T20:22:04,738+0000 lvl='INFO', log='LoggingFilter', th='catalina-exec-4', xff='', rId='65d1ead2-25cd-46ac-b190-05ca22be9260', aRId='4', tRId='1', 149 * Server out-bound response
149 < 408
149 < Content-Type: application/json
149 < Vary: Accept-Encoding
149 <

[stephane brossier]

Greg,

If you have any chance, could you verify the steps we have tried to repro the issue, and comment on the ticket if you think this is not the right to reproduce the issue? Also, which version are you running?

Thanks,

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-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/a18fb7bd-ea4e-4fc7-a074-8bb7c997c5c0%40googlegroups.com.

[gpre...@womply.com]

> 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/a18fb7bd-ea4e-4fc7-a074-8bb7c997c5c0%40googlegroups.com.
>
>
>
> For more options, visit https://groups.google.com/d/optout.

We're using 16.8 currently.


Best I can tell, it is related to not having a default payment method and not having the AUTO_PAY_OFF tag set.