You could try turning off the "Split Pay Pref Per Shp Grp" option on the product store.
Regards Scott HotWax Media http://www.hotwaxmedia.com On 9/12/2010, at 11:05 AM, Adam Heath wrote: > We recently had some payments get rejected by authorized.net. The ofbiz > install in this situation allows for multiple ship groups. The duplicate > detection code on the authorized.net side checks the credit card info, plus > payment amount, and if they match, rejects the request, saying it is a > duplicate. > > The issue here, is the grandmother situation. A grandmother could buy 5 > copies of a book, or a sweater, or something, and send them to her 5 > grandchildren. This will cause 5 payment method requests, all identical, to > occur. > > If separate AUTH/CAPTURE methods are used, the AUTH will succeed, a > transaction refnum will be returned, and the final CAPTURE will also succeed. > > However, when the combined AUTH_CAPTURE is used, there is no intermediate > transaction refnum, so this duplicate error shows up. > > Adding a x_duplicate_window=0 is the suggested fix(as returned by the > google), but that disables the security feature, so I don't know if it is > correct. > > Is there a better way for this to be fixed? Maybe ofbiz should aggregate all > payments requests that can be issued at the same time. Maybe it could have a > request falloff algorithm, that is per-credit card(or other classification), > to support not hitting the processor so quickly. Or maybe something else. > > I plan on committing x_duplicate_window=0 into the buildAuthTransaction > method of AIMPaymentServices in the next few days, unless others speak up > with alternative plans of action.
smime.p7s
Description: S/MIME cryptographic signature
