AbleCommerce Shopping Cart Software

hi all,
if someone has underpaid on an order(e.g. another item added to order later) and i attempt to process a second payment via the 'add new payment' button on the payment tab for the order - the transaction fails due to a 'malformed card number 3051' error code using the sagepay gateway. looks like the card number entered is not being processed correctly!

3051 : The CardNumber field is required.

the same card details will work fine at the end of the checkout process, so at the moment i have to log on as the user and create a new order from scratch for additional items, this is a real pain if the original order hasn't shipped yet!

is this a known issue?
is there a fix?

any help would be much appreciated.
AW

We've been trying on our end to reproduce this without success. Is there any chance you can provide a screen shot of the problem screen? You could post it inline to the thread or send via PM if it has sensitive information.

hi, thanks for looking -
i've found that the problem occurs because of an event trigger, the problem doesn't concern the Protx.dll

in commercebuilder.Payments.PaymentEngine

the method private static void DoAuthorize(AuthorizeTransactionRequest request, bool async) starts the transaction--- AbleContext.Current.Database.BeginTransaction();

this causes the public override void BeforeSave(object entity) method in commercebuilder.Payments.PaymentRepository to strip out the "SecurityCode" from the AccountData in the Payment object.

unfortunately this all happens before attempting the authorization back in DoAuthorize(AuthorizeTransactionRequest request, bool async)

so the authorization attempt will fail if the "SecurityCode"(CV2) number is required.

Andrew.

Logan, as you are checking on this, could you check 7.0.7 also? We have had a client having problems with weird error messages when trying to submit payments (reported from a customer of theirs). I emailed a bug about it the other day and Katie contacted me and I am waiting on screenshots of the transaction in the authorizenet account.

With the additional information we were able to solve this. We can't offer an immediate workaround for R3 because it requires a change in our compiled source. However the problem will be solved for the R4 release.

Judy I do not believe this would impact the 7x line based on what is triggering the security code to be wiped out.

Thanks, Logan. I was grasping at straws. It's hard for all of us when we get info about a problem third hand and then can't duplicate the problem the customer says they are seeing. You don't know if it's a real problem, user error, or what.