7/11/2014 4:20:54 PM
paymentMethodId on the account, so that payment state machine will still run
and will end up generating a payment bus event (That can be caught by the system, such as the overdue module to move overdue state).
|
7/10/2014 10:36:29 PM
event outside of transaction for when payment did not complete (there was no transaction)
Fix Payment events (remove invoiceId, paymentNumber, ...)
|
|
|
|
|
|
|
7/10/2014 6:10:52 PM
...)
|
7/10/2014 5:38:01 PM
be consistent (and explicit)
|
7/10/2014 5:19:34 PM
to encapsulate (hide) required knowledge about the state machines
and refactor the payment code to rely on those new abstractions.
(We could remove some of the hardcoing existing in these classes by introducing additional attributes on the state machine xml (isTerminal, isSuccess, isInit,...)
but there will always be a bootstrap issue to solve, and so those classes need to exist)
|
|
|
7/10/2014 12:13:36 AM
where the underlying transaction was succesfull
(This ensure that any PaymentControlPluginApi onSuccessCall() will end up being called)
Part of this work included:
- adding the paymentAttemptId in the transactions tables
- adding unique index for invoice_payments(payment_id, type) (to ensure idenpotency of retry calls, but plugin also checks on its end)
|
