duplicate transaction ids for authorized.net

[Adam Heath-2]

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.

[rohit]

Hi Adam,

Though this is not directly related to the problem that you are facing, but i think it makes sense to add this here in case someone picks up to amend the code.

Credit card processing has another problem when we have multiple items in an order and a given item has to cancelled.

For eg. if there are 2 items in an order, say X is costing $60 and Y is costing $40. When the order is placed, an authorization of $100 is made but if say later when the order is processed and X is to be shipped while Y is to be cancelled, ofbiz correctly charges the credit card $60, but at the same time makes another authorization for $40 for the item Y which is cancelled and would not be processed or shipped.

This happens in spite of the order being marked as 'Completed'. I think its a completely redundant and un-necessary authorization, and also the business ends up paying additional authorization fees.

I think a Jira issue, can be opened for this. If this is not a bug, i guess it sure does not make any business logic.

Please let me know your comments.

Thanks,

Rohit

[Scott Gray-2]

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.

[Ean Schuessler]

That would suppress the problem, but shouldn't splitting work without being flagged as a duplicate?
----- "Scott Gray" wrote:
> You could try turning off the "Split Pay Pref Per Shp Grp" option on the product store.

--
Ean Schuessler, CTO
[hidden email]
214-720-0700 x 315
Brainfood, Inc.
http://www.brainfood.com 

[Adam Heath-2]

On 12/09/2010 08:32 AM, Ean Schuessler wrote:
>
> That would suppress the problem, but shouldn't splitting work without being flagged as a duplicate?
> ----- "Scott Gray" wrote:
>> You could try turning off the "Split Pay Pref Per Shp Grp" option on the product store.

It also might be illegal.  You shouldn't capture the payment until the
ship group is shipped, and it's entirely possible that a
multi-shipgroup order would have 2 shipments packed by separate users,
within the time window that this security feature attempts to implement.

[Scott Gray-2]

On 10/12/2010, at 5:17 AM, Adam Heath wrote:

> On 12/09/2010 08:32 AM, Ean Schuessler wrote:
>>
>> That would suppress the problem, but shouldn't splitting work without being flagged as a duplicate?
>> ----- "Scott Gray" wrote:
>>> You could try turning off the "Split Pay Pref Per Shp Grp" option on the product store.
>
> It also might be illegal.  You shouldn't capture the payment until the ship group is shipped, and it's entirely possible that a multi-shipgroup order would have 2 shipments packed by separate users, within the time window that this security feature attempts to implement.

Nothing illegal about it, the only difference in functionality is that you end up with one auth for the larger amount and then a capture per shipment.  Split Pay Pref Per Shp Grp is a relatively new feature (few years old) and I believe was mostly intended for supporting differing payment methods per ship group.

And yes your problem could still arise and I wasn't suggesting this as a fix so much as a workaround.

Regards
Scott