[
https://issues.apache.org/jira/browse/OFBIZ-896?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Jacopo Cappellato closed OFBIZ-896.
-----------------------------------
> Important issue with rollbacks on payment processing
> ----------------------------------------------------
>
> Key: OFBIZ-896
> URL: https://issues.apache.org/jira/browse/OFBIZ-896
> Project: OFBiz
> Issue Type: Bug
> Components: accounting, order
> Reporter: Jacopo Cappellato
> Assignee: Andrew Zeneski
> Priority: Critical
>
> From a recent thread on the dev list:
> ===========================================
> I really think I'll need (at least) some help to fix this; here are some more
> details.
> I don't think that we can fix this by requiring a new transaction.
> Let's focus for example the capturing process (but the same issue is present
> in the auth/release/etc... transactions):
> a) the main method involved is PaymentGatewayServices.capturePayment(...)
> b) this method internally pulls the service name to use to process the
> payment from the store settings and it runs the service requiring a new
> transaction (see line 1413)
> c) the above method, "capturePayment", is called by other methods of the
> PaymentGatewayServices class, for example by the captureOrderPayments
> service/method (see line 1147)
> The issue is that the captureOrderPayments method, after that the call to the
> capturePayment method is (succesfully) done (i.e. the funds have been
> captured) performs other logics, and for example a few lines below it calls
> another method that could fail and if it happens it returns an error causing
> a rollback (line 1166).
> Of course the rollback will not rollback the remote transaction.
> The problem is more complex than this, since, even if the
> captureOrderPayments service will return a success, there are other services
> triggered by it that could fail; this would be partially addressed requiring
> a new transaction for the captureOrderPayments service though.
> Ideally, but I know it is not possible, nothing should happen (that could
> fail) after the transaction has been issued
> How can we fix this?
> Jacopo
> David E. Jones wrote:
> >
> > Jacopo,
> >
> > Yeah, that's a bit of a scary bug. What should probably happen is that the
> > code that stores information related to the credit card transaction should
> > be separated from everything else. If it is in it's own service already
> > then that service can just have the require-new-transaction attribute set
> > to true. If not, then it should be split out into its own service with that
> > attribute set so that it runs independently (in terms of success/failure)
> > of the other stuff going on.
> >
> > This is a pretty big issue... Is something you're looking at working on? If
> > you're short on time and could write up whatever details you've found we
> > can probably get one of our guys on it.
> >
> > -David
> >
> >
> > On Apr 13, 2007, at 10:55 AM, Jacopo Cappellato wrote:
> >
> >> I think there is an important issue with online payment processors in
> >> OFBiz.
> >> I'm not going into the details, because I think it is better to discuss
> >> this issue in general, but this is something that really happened at least
> >> with one of my customers.
> >>
> >> When an order payment is processed (authorized/captured), in OFbiz a chain
> >> of events/service calls (ecas etc...) is triggered.
> >> Everything is wrapped inside one transaction so, if something goes wrong,
> >> the rollback brings everything back to the original situation.
> >> Unfortunately, if the error happens after the online transaction has been
> >> issued, OFbiz will not know that the payment has been authorized and/or
> >> captured.
> >>
> >> What is in your opinion the best way to handle this scenario?
> >>
> >> Jacopo
> >>
> >
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
