3
Currently, when a Call Center order that has previously gone through Completion is subsequently modified (so, an order amendment), if the order total changes, the Call Center Credit Card Payments mechanism will void the existing auth, and then try to get a new auth.
In the case where the existing auth would have been sufficient to cover the new order total, the current logic is voiding the existing auth and getting new one for the lesser amount. Example: say the original order and payment total was $2000, and the new order total after amendment is $1900 -- the 2000 auth is voided, and a new one is attempted (and which may be declined) for 1900. This seems unnecessary as we would be able to capture the entire new total of 1900 off an auth for 2000 without issue. Further, in our case with high order values, it happens very often that the void auth is not honored by the bank, and the new auth(s) are declined due to insufficient open-to-buy on the customers' payment cards.
Similarly, in the case where the order total increases, it would also be very nice to again use the existing auth and get an incremental auth for the remainder. Again, in the case where a $2000 order goes to $2200, rather than authorizing a customer's account for a total of $4200 that may take time to fall off their open-to-buy when their bank doesn't support void auth, it would be a much better customer (and commercial) experience to auth for 2000, and then auth for 200.
The ultimate impact here is that in our use case with rather high average order values, more often than not, literally any change to a Call Center order ends up in us losing the sale when the new auth declines and the customer backs out of the transaction.
In the case where the existing auth would have been sufficient to cover the new order total, the current logic is voiding the existing auth and getting new one for the lesser amount. Example: say the original order and payment total was $2000, and the new order total after amendment is $1900 -- the 2000 auth is voided, and a new one is attempted (and which may be declined) for 1900. This seems unnecessary as we would be able to capture the entire new total of 1900 off an auth for 2000 without issue. Further, in our case with high order values, it happens very often that the void auth is not honored by the bank, and the new auth(s) are declined due to insufficient open-to-buy on the customers' payment cards.
Similarly, in the case where the order total increases, it would also be very nice to again use the existing auth and get an incremental auth for the remainder. Again, in the case where a $2000 order goes to $2200, rather than authorizing a customer's account for a total of $4200 that may take time to fall off their open-to-buy when their bank doesn't support void auth, it would be a much better customer (and commercial) experience to auth for 2000, and then auth for 200.
The ultimate impact here is that in our use case with rather high average order values, more often than not, literally any change to a Call Center order ends up in us losing the sale when the new auth declines and the customer backs out of the transaction.
STATUS DETAILS
Needs Votes