Better handling of 0.00 total response from gateway implementations
-------------------------------------------------------------------
Key: OFBIZ-246
URL:
http://issues.apache.org/jira/browse/OFBIZ-246 Project: OFBiz (The Open for Business Project)
Issue Type: Bug
Components: accounting
Reporter: Jacopo Cappellato
Priority: Minor
Copy of an old issue from Alexander Heiss:
When we get back a 0.00 processAmount from an external payment implementation, setting the total to capture back to the max amount for the order is a bad idea; should at least change to get remaining total of payments left to be paid instead.
~line 1159 of PaymentGatewayServices change:
amount = paymentPreference.getDouble("maxAmount");
to
double orderTotal = orh.getOrderGrandTotal();
double totalPayments = PaymentWorker.getPaymentsTotal(orh.getOrderPayments());
double remainingTotal = orderTotal - totalPayments;
amount = new Double(remainingTotal);
This assumes you want to always charge rest of order to this card. Could also possibly check against the maxAmount to make sure we don't go over, but not too sure at the moment what to do if total left on order is over origional maxAmount, just cap it?
All Comments Work Log Change History Sort Order: [navigator.ascending.order]
Comment by Andrew Zeneski [27/Aug/04 12:34 PM]
[ Permlink ]
I am thinking if we get back 0.00 from the gateway, that would mean that 0.00 was authorized. This probably should not capture at all in this case. Have you seen this actually happen?
Comment by Alexander Heiss [27/Aug/04 01:07 PM]
[ Permlink ]
0.00 back from the implementation may not necessarially mean that there was a successful capture of 0.00. In both cybersource and clearcommerce, a 0.00 is returned when there is no ccAuthReply_amount sent back (cybersource) or there is some sort of error.
I am using older implementation of cybersource, but I've seen a null ccAuthReply_amount come back from them when an attempt is made to capture, and a 102 (REJECT).. invalid data.. is returned. The request to them is fine, but the auth being captured is expired.
Do we want to use 0.00 in the implementations, or maybe change to a -1 or something? It's time consuming to test expired auths but I think the main issue here is setting 0.00 in the implementation when we really dont get a 0.00 back (even though $0 was actually captured in the transaction).
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
Locked
