|
|
|
|
12/16/2016 8:53:02 AM
the current behavior under atypical scenarios, namely:
* Complex timelines with various same-day changes do not trigger any bounds
* Duplicate (buggy) billing events do not lead to invoicing errors
* If multiple fixed items for a given subscription and start date already exist on disk, the next run will not re-generate one
* If multiple recurring items for a given subscription and service period already exist on disk, the next run will not complete (the merge logic will detect the existing bad state, i.e. double billing)
While the system can already handle these bad cases, it's still possible that either our items generation
code (proposed items) or the merge algorithm have issues in even more complex setups (repairs, adjustments, etc.).
To pro-actively detect these, this patch introduces new internal safety checks on the resulting list:
* At most one FIXED item should be present for a given subscription id and start date
* At most one RECURRING item should be present for a given subscription id and service period
The behavior can be disabled by setting org.killbill.invoice.sanitySafetyBoundEnabled=false.
See https://github.com/killbill/killbill/issues/664.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/15/2016 7:20:41 PM
sure payment id/key, transaction id/key and processed amount/currency
are correctly passed to all PaymentControlPluginApi callbacks.
In particular, make sure that they are populated even for the priorCall
when completing a transaction.
This fixes https://github.com/killbill/killbill/issues/617.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/15/2016 4:54:28 PM
Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/15/2016 1:00:15 PM
the AdminPaymentApi
Make sure the link invoice-payment is updated after fixing a transaction
from PAYMENT_FAILURE to SUCCESS.
As part of it, when IncompletePaymentAttemptTask completes a run and the resulting
transaction is success (i.e. SUCCESS or PENDING), the future retry associated
with the completed attempt is removed.
See https://github.com/killbill/killbill/issues/625.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/15/2016 8:59:48 AM
<pierre@mouraf.org>
|
12/15/2016 8:58:23 AM
sure the link invoice-payment is updated after fixing a transaction
from SUCCESS to PAYMENT_FAILURE.
To do so, the fixPaymentTransactionState implementation now updates the
payment attempt associated with the transaction being fixed.
This also fixes the shortcut in IncompletePaymentAttemptTask, where control
plugins weren't called during the completion.
See https://github.com/killbill/killbill/issues/625.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/15/2016 6:15:38 AM
that we won't attempt any retry in that case, because the transition was
triggered by an API call.
See https://github.com/killbill/killbill/issues/625.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
12/15/2016 5:26:06 AM
invoice send an InvoicePaymentErrorInternalEvent event upon processing
a PENDING payment: this is used as a trigger for Overdue (which doesn't listen
to pure payment events anymore, but just InvoicePaymentInfoInternalEvent / InvoicePaymentErrorInternalEvent).
The name could be a bit misleading but I'm not sure it's worth introducing another
internal InvoicePaymentPendingInternalEvent event for this. The name does match
the state on disk though (success = false while the payment in PENDING).
This internal event will be sent as an INVOICE_PAYMENT_FAILED on the external bus.
Listeners should make sure to retrieve the full payment to act on it (which is
the best practice anyways).
If the payment transitions to success, InvoicePaymentInfoInternalEvent is
subsequently sent (INVOICE_PAYMENT_SUCCESS on the external bus).
See https://github.com/killbill/killbill/issues/625.
Signed-off-by: Pierre-Alexandre Meyer <pierre@mouraf.org>
|
