A few people reported Authorize duplicate charges. this issue concerns me deeply as one of my clients (who refuses to launch his site for some strange reason) will be using Authorize.net.
The thing is, Magento team doesn’t make any comment on this, and there isn’t other report/post on similar issue on other gateway payment. I have my whining about Magento, but since we have not heard people using other gateway payment service having similar issue, I am incline to think maybe the problem is with Authorize API more than Magento? I followed closely on the google checkout thread that Anna and others had, which, took quite a long finding that the problem was on Magento (or bug on google checkout API that magento team didn’t aware). Maybe this is something that Authorize API has issue with and has not discovered by people (users/developers from other eCommerce software), yet Magento accidentally stepped on the minefield because it uses Zend framework and there is incompatibility issue (this is quite possible as Magento is the only eCommerce software using Zend Framework)? If this is the case, it’s like the annoying IE bugs, that Microsoft won’t fix it, so the web designers have to come out all kind of hacks to make it work? Or should we hope Magento team work with Authorize and Zend Framework people to find the cause and work out a solution? I don’t know enough to give good suggestion (not to mention people won’t care ), but I am pretty good at trying to narrow down the cause of the problem by making speculative assumption and paying attention to small detail.
I hope people who have encountered Authorize duplicate charges issue, give feedback, symptoms, and how you solved it; if you haven’t solved it yet, have you or have you have your client contacting Authrorize tech support to find out maybe problem is with Authorize API, not Magento?.
I also hope people using other gateway payment services can report whatever abnormal problem they (or their clients) have experienced.
This really needs to be taken care of. I understand that you are trying your best with Magento and that you are working hard on it. I appreciate this greatly! I know that we have to wait and work things through when implementing new procedures.
I cannot come in every morning and fix a mistake. I am getting calls from angry customers. I am calling people who get angry with me in return. I am spending time tracking down customers. I am already spending a lot of time on the orders like making the packing slip for the warehouse which I do expect that I may have to do for the first couple weeks when implementing the new system. However, I have also been spending a lot of time on other issues like orders being charged twice, not getting the order but receiving the charge and others which is taking up a lot of my time. These things I understand will need to be worked out as well but we are going back and forth on them being fixed and not fixed. And now, I am fixing problems that shouldn’t happen more than once.
I have posted about this same problem here, here, here, and also a bug report here.
You have been connected to Lilith M..
Lilith M.: Hello Lance! How can I help you today?
Lance Monotone: Hello Lilith M.! We are getting multiple charges for some transactions. Is there some kind of transaction threshold setting to fix this? Are we being charged for voiding these transactions?
Lilith M.: You are charged for all transaction attempts regardless of their final status. Are these transactions being submitted by your website? If so, do you know about how far apart the duplicates are?
Lance Monotone: They are sent at virtually the same time. I am the developer and this is my client’s site. I’m working with the Magento cart. I have programmed the Process Transaction button to be disabled after clicking, so I don’t think it’s a problem of a double-click.
Lance Monotone: Are other Magento users being heard from on this?
Lilith M.: Hmm, and have you checked to make sure Magneto is not submitting two transactions, perhaps one to “test” the card first?
Lilith M.: I have only spoken to one other Magneto merchant, personally, and she was not encountering the issue.
Lance Monotone: Also, are test transactions (using the test card number that Authorize provided) charged as well?
Lilith M.: However, there is a duplicate transaction filter that might help. It may involve accessing the code directly. Would you like those details?
Lance Monotone: As far as I can tell the order is only placed once.
Lance Monotone: Yes please!
Lilith M.: Any test card number would not have a valid account backing it, and so if you submit a test card and Test Mode is OFF, then it would be declined--otherwise, if Test Mode is on, you would get a positive response, but no real transaction would be processed.
Lance Monotone: Right, but are we charged for the test? I’ve been doing a lot of them trying to figure this out.
Lilith M.: Not while Test Mode is on, no.
Lance Monotone: Good news.
Lilith M.: If you wish to adjust the Duplicate Window applied to transactions submitted from an external location, such as a website or shopping cart, you may do so by adding the variable value pair “x_duplicate_window” to your website script.
If you are unable to adjust or add this variable to your shopping cart settings, please contact your shopping cart support team for additional assistance in this regard. The variable x_duplicate_window indicates in seconds the window of time after a transaction is submitted during which the payment gateway will check for a duplicate transaction.
The maximum time allowed is 8 hours (28800 seconds). If a value less than 0 is sent, the payment gateway will default to 0 seconds. If a value greater than 28000 sent, the payment gateway will default to 28000. If no value is sent, the payment gateway will default to 2 minutes (120 seconds).
Lance Monotone: So something like x_duplicate_window = 60; would mean 60 seconds? Should the 60 be a string or a number?
Lance Monotone: And actually, if it’s defaulting to two minutes, this probably wouldn’t work.
Lilith M.: It’d be a number--but I bet Magneto may be setting x_duplicate_window to a smaller value--maybe even 0.
Lance Monotone: Something to look into but I don’t think it’s being set within Magento. I’m looking at the code and I see x_version, delim_data, delim_char, and relay_response, but no duplicate_window. What is relay_response? It’s set as false.
Lilith M.: That is for one of our APIs where our own payment form would be used. Magneto shouldn’t be using our payment form and so would have Relay Response turned off.
Lilith M.: Do you have a set of transaction IDs where you are seeing duplicates, so I can check?
Lance Monotone: Just a second…
Lance Monotone: XXXXXX, XXXXXX for XXXXXX
Lilith M.: Please hold while I review your account information. Thank you.
Lilith M.: Lance, it looks like the first transaction (XXXXXX) was submitted nearly 4 minutes and 30 seconds after the first transaction (XXXXXX).
Lance Monotone: XXXXXX, XXXXXX, XXXXXX for XXXXXX..this one looks like it was triplicated.
Lilith M.: In theory, you could add x_duplicate_window and set it to the maximum value of 28800, which means an eight-hour delay before we accepted any further duplicates.
Lance Monotone: Maybe the first wasn’t actually a dupe. We’ve been having a lot of problems with the cart. Some of them I’ve been able to resolve and that may have been a case there.
Lilith M.: I’m checking the other three right now.
Lance Monotone: Would that mean that if someone put in the wrong cc info and it was rejected they’d have to wait eight hours? What is the duplicate checking for? Invoice id, cc number, or...?
Lilith M.: No, changing the credit card number, or any other part of the data submitted, would cause the transaction to not be a duplicate. This would include amount, name, address, etc.
Lance Monotone: OK.
Lilith M.: And as for the three for XXXXXX--you’re right, all three were submitted within two minutes, two seconds. Odd that there does not seem to be a field for x_duplicate_window here.
Lance Monotone: I see a problem there and maybe one reason why the duplicate window is not working… the invoice number for each multiple is changing.
Lilith M.: That’d certainly do it.
Lance Monotone: Of course maybe it’s not working because it’s not set? But should it default anyway, or should it always be shown within the transaction details?
Lilith M.: It is on as a default and set to 120 seconds, system-wide, unless we are told to override it by having x_duplicate_window posted to us, with a different value.
Lance Monotone: Is there anything within the API to specify which field to check for dupes? For instance, the cc number?
Lilith M.: No. Let me give you the exact fields we check for duplication:
Lilith M.: MerchantID - x_login
Credit Card Number - x_card_num
Expiration Date - x_exp_date
Transaction Type - x_type
Bank Account number - x_bank_acct_num
Routing Number - x_bank_aba_code
Purchase Order Number - x_po_num
Amount - x_amount
Invoice - x_invoice_num
CustomerID - x_cust_id
First Name - x_first_name
Last Name - x_last_name
Company - x_company
Address - x_address
City - x_city
State - x_state
Postal Code - x_zip
Country - x_country
Duplicate Window - x_duplicate_window
Lilith M.: You may need to scroll up to view the full response.
Lance Monotone: So if any of those are changed, the dupe window won’t catch it?
Lilith M.: Correct, yes.
Lilith M.: And, the invoice number is listed as one of the fields checked.
Lance Monotone: Hmmm. Well I guess I’ll need to keep looking. I don’t suppose there’s anyway you can reverse the charges my client incurred for voided transactions? Just asking. : )
Lance Monotone: It would make me look a lot better after the trouble we’ve been having with this installation.
Lance Monotone: Magento’s not quite ready yet.
Lilith M.: I understand. I was able to reverse $10 for a late payment fee that was charged a few months back, so that will reduce your client’s bill by $10 next month.
Lance Monotone: That is really nice of you. Thanks for that and for all your help. Take care.
Lilith M.: Thanks for dropping by, Lance! Please feel free to contact us again with further questions. If you would like a copy of this session for reference, please click on the “Print” icon.
Thank you for using Authorize.Net. Please search our new online Knowledge Base for answers to Frequently Asked Questions:
http://www.authorize.net/help
So, as far as I can tell, there is a bug when the transaction is submitted to Authorize.net (and I don’t want to lead anyone down the wrong path (not that anyone’s out here walking around) but it seems to happen to MasterCard more often).
For some reason, some transactions are sent multiple times, which would be bad enough, even though the dupes should be caught by the Authorize ‘x_duplicate_window’ default of 2 minutes. They’re not being caught because the invoice number is being incremented as well, defeating the safeguard.
What is also strange is that only the last of the incremented orders are actually being recorded within Magento. The customer is being charged for invoice 001, 002, and 003 (which are actually the same order)...but only 003 shows up in the Orders table.
I don’t expect an answer from the “Team”. But surely they can see that there is a big problem here that will only get bigger as more stores come online?
What is also strange is that only the last of the incremented orders are actually being recorded within Magento. The customer is being charged for invoice 001, 002, and 003 (which are actually the same order)...but only 003 shows up in the Orders table.
That’s exactly what happened the two times it happened to us - though I’m still pretty confident both errors where the end user after discussing with them. It’s not been a consistent problem at all, either.
I did notice, though, that the bug you submitted has been assigned, so hopefully it is being looked into.
Lance, is your client still using Magento store and any more duplicate transaction (I sincerely hope not)? I am curious if you have done anything special after the nice chat with authorize’s support.? Client finally have his authorize account info for me, I am going to run a few test mode later, and is thinking perhaps I should advice him not to accept MC for the time being.
Haven’t seen an update from Yoav, I guess this issue is yet to be solved?
No, we have restored their old cart (www.mebath.com) because of the lack of response from the ‘Team’ and will be switching to Zen or another cart later this month (I am not happy about the dent in my reputation, not to mention the dozens of lost hours). The issue has not been resolved as far as I know. The only thing I could think of doing to alleviate the problem was to change the transaction mode from ‘Capture and Authorize’ to just ‘Capture’ and let my client take care of authorizing the card on the Authorize.net site. However that’s not reasonable for them because their volume is too high and I don’t know whether that would fix the other issue of charges to our customers cards without recorded orders in Magento.
You are a Pro Member, doesn’t that mean that you pay for support? What is that getting you?
PS. I’ve always wanted to ask you, what does your signature mean? Is that a fable?
Lance, thanks for the update again!
Sorry to hear that you have to restore to old cart. While Magento team isn’t response but I am sure they are looking into the matter as Yoav responded, no update yet probably means the issue has not been solved and no cause has found.
I have to stick with magento for this site as I cannot back off, and have no alternative, therefor I must have faith in Magento team that this issue will be solved soon
About ‘Capture and Authorize’ option, I notice in the Authorize account, under ‘Virtual Terminal’, there is a ‘Upload Transactions’ option that mentions “The File Upload Capabilities setting allows you to upload a file with multiple transactions to the Payment Gateway via the Upload Transaction Files feature.”, so maybe it will still work for high volume transaction likes your client?
Pro Member service was retired, I have not purchase a professional service support yet, so is not getting anything special except this wonderful free eCommerce software. I have 4 free professional service ticket support though I think, likely will use one soon if I am still getting now way.
About my signature, it’s some holly message I got from Allah and the God (the one who blesses America) in my spiritual quest, but I have not heard anything from Buddha yet, so yeah, that likely is a fable
The site is hosted with Bluehost, but we are going to try once more with a different host, Godaddy, where my clients have their domain names registered. I think some of the problems came from trying to run such a resource-heavy application in a shared environment. So we’re going to beef up the hosting account and give Magento a trial run around the end of the month. Hopefully by then the ‘Team’ will have fixed some of these bugs and we’ll be able to go live again. If not, we are going to have to switch to Zen.
As for your spiritual quest, if you and Ahming are the only ones here, that would mean that all these hours spent with Magento have truly been in vain! Meanwhile, mankind is still limping along, and God hasn’t got much reason to smile on America much these days. *sigh*
I have found and fixed an issue with this that was causing it appears, all of our duplicate charges. Due to the transactional nature of the order creation piece, if the charge is submitted and then the order fails at any point afterwards, the ANET charge will happen without creating a corresponding order in Magento.
What I discovered was causing this was a failure in the check for an existing email address when registering a new account during the one page checkout process. So if the user’s email address already exists in the system and they enter it again in the Billing portion of the checkout, it was not being caught until they finished and clicked ‘Place Order’. At this point, the order object is created, the payment submitted, and when the system tries to store the order object it fails due to the duplicate email, and the order is not stored, but the charge has already been created. It appears that the reason the existing check was failing was because the website id was not being included and when multiple stores exist in the system, the email was not found.
My fix for this was to fix the validation of the email before proceeding beyond the ‘Billing’ step in one page checkout, by including the website id. The offending code resides in app/code/core/Mage/Checkout/Model/Type/Onepage::saveBilling() where it checks for an esisting email address, so I simply defined a new class in my custom module to overload that function:
class Mymodule_Checkout_Model_Type_Onepage extends Mage_Checkout_Model_Type_Onepage {
/** * This method is called by One Page Checkout JS (AJAX) while saving the billing information. * * @param unknown_type $data * @param unknown_type $customerAddressId * @return unknown */ public function saveBilling($data, $customerAddressId) { //check and make sure the email address if present, doesn't already exist if(!empty($data['email'])) { $customer = Mage::getModel('customer/customer')->setWebsiteId(Mage::app()->getWebsite()->getId())->loadByEmail($data['email']); if($customer->getId()) { $res = array( 'error' => 1, 'message' => Mage::helper('checkout')->__('There is already a customer registered using this email address') ); return $res; } }
@bott, thank you so much for sharing your finding and the code.
Can you please clarify ‘so I simply defined a new class in my custom module to overload that function’. If I use your code, do I insert it in the onepage.php file right after ‘ public function saveBilling($data, $customerAddressId)’?
Hopefully Varien will fix it with your code it in no time, and release a patch and I don’t need to do it myself
Thank you again! My client’s site still not launched yet because he is too busy with his retail store, but I’d been worried about this issue so much.
Yes, that is a good point, we fixed it in the same way for 1.1 (moving email validation from step 6 to step 2).
There is one more thing that can cause order creation to fail after the transaction data is submitted to payment gateway - network timeout when getting a response (or getting a malformed response though it’s much less probable). In this case the customer will get ‘Payment gateway error’ general error message popup (at this moment transaction is already posted in Authorize.net but order was not created in Magento as we didn’t get a response). And if a customer will click on “Place order” button again (that I think at least a half of customers will do) - it will post one more transaction.
I don’t see any way to handle the second case automatically, so we will send a notification email (containing shopping cart data, addresses and totals) to the store owner once it happened.
I will update you once an update and/or patch is available.
), but I am pretty good at trying to narrow down the cause of the problem by making speculative assumption and paying attention to small detail.
