Details
-
Bug
-
Status: Closed
-
Minor
-
Resolution: Abandoned
-
None
-
None
-
None
-
Bug Crush Event - 21/2/2015
Description
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).