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.
- duplicate transaction ids for authorized.net Adam Heath
-
