I see there are some people that got Amazon’s payment module working w/ Magento 1.5 and 1.6
I’m on 1.6.1 and I ALMOST have it working. Everything works great in Sandbox mode, when I have “Sign_XML_Cart” option disabled from the Magento side and also have it disabled from the Amazon side in the Checkout Pipeline Settings.
However, when this option is enabled, as it needs to be in production mode, I get this error from Amazon:
The order could not be authenticated. Detail: Your signature [xxxxxxxxxxxxxxxxxxx=] does not match the signature that we expect.
Was anybody else able to solve this issue?
Thanks
The problem was that I had an extra space on the end of one of my API keys, when I copied and pasted over from Amazon's site. That extra space will cause a signature mismatch.
Related
I am setting up a megento shop but while testing I get the following error when paying by card using ebizmarts Sage Pay module:
Payment has failed, please reload checkout page and try again. Your card has not been charged.
Does anyone know the solution to this problem?
Regards,
Daniel
There is a support forum for the free plugin here http://ebizmarts.com/forums and if you are using the PRO module, you can just use the contact form here http://ebizmarts.com/contact-us
Also, the problem you mention is described on the Wiki here http://wiki.ebizmarts.com/sage-pay-common-problems
FIXED
From what I can see and for whatever reason, Magento was loading the "info.phtml" file from the theme/default/checkout/onepage/review folder, rather than the one in the sagepaysuite folder.
I copied in the above code to the relevant position to the default info.html file, and it's working now.
The staging server was loading the sagepaysuite/checkout/review/info.phtml file correctly, hence it was working.
I am working on a Magento store and if I change anything related to shipping in the back-end it gives me an internal server error (500 Error). This only happens when trying to save the shipping configuration settings--I just changed the tax settings with no problem. I have tried everything from resetting the permissions to editing the .htaccess file.
Screen shots:
I get this:
It is allowing me to change any other setting though..
If anyone knows why this might be happening please let me know.
From the additional information you posted in the comments section, it appears that your server does not have the PHP bindings for mcrypt installed.
Your webhost will either need to install mcrypt, or you'll need to find another host that does.
The requirements for running Magento are listed on the website: http://www.magentocommerce.com/system-requirements
Every order placed from the frontend of our Magento store logs a "Wrong order ID" exception even though all orders seem to be going through with no problems. Orders also seem to take a lot longer to complete than they should. If I place an order from the admin, it's virtually instantaneous and does not log any errors. What's different between frontend and backend orders? Why are these errors being logged every time even though no error really occurred? Any suggestions?
Thanks!
Per the change log for Magento 1.7.0.0 (which came out in April), they think they've fixed the problem:
Fixed: “Wrong order ID” exception in PayPal Express module under heavy load
Can anyone confirm that upgrading to Magento 1.7 does indeed fix the problem? Every time I've looked at it, it does seem to be a PayPal Express issue (our payments normally go through PayPal Pro and that doesn't seem to have errors).
So... we finally found a permanent solution to this for Magento 1.6. And we can confirm that this has been fixed in Magento 1.7.
Full explanation and code here:
Magento Paypal IPN Wrong Order ID – SOLVED
We had this same exception in Magento 1.6.1 showing up in exception.log. The problem for us was that the Order Number and Invoice Numbers were out of sync.
For some reason, when using PayPal Express, it causes the order to not be fully processed and logs the exception: “Wrong Order ID”. The worst part was that it was erratic… sometimes it would fail, other times it was fine.
THE SOLUTION:
http://www.magentocommerce.com/magento-connect/fooman-sameorderinvoicenumber.html
Thanks for a great extension from Fooman! Just install their “SameOrderInvoiceNumber” extension, remember to enable it in “Configuration | Sales | Order Numbers” and you’re all set!
Solved the problem for us on Magento 1.6.1… don’t mess with core code!
Ok... So my other solution didn't soIve the problem for us either. Spoke too soon. Although this helped it didn't get rid of the error completely.
We did however find a definite clear link between server load and this IPN error. Detailed analysis here:
http://www.bigdune.net/geek-blog/magento/60-magento-paypal-ipn-wrong-order-id.html
Sorry, but it doesn't seem like there's a quick "code fix" for this one.. not that we could find yet.
I have a problem with debugging a thing (not a real error) in Magento (CE 1.4.1.1).
For a payment module I've adapted, some additional payment fee is incorporated and is showing up on selection of the particular payment method. Works fine, no problems.
A client has the OneStepCheckout plugin installed. Inside it, the payment method works fine too (small problem: payment fee is showing up after the grand total, but that's not the issue, just for completeness of my question).
So, everything is working fine, even with some other payment modules installed. That is, working fine on dev and test! On the live server however, the extra fee does not show up! I've locally installed the other plugins that are installed on the live server as well, to see if there are any conflicts among them. None whatsoever. The Extension Conflict extension does not indicate any class overwriting problems either. Of course, I've cleared the cache. Several times.
So my question is a rather general one:
How to proceed?
What can I do and how to actually see what's going on and NOT break the live environment ? As far as I know, there is no staging server (there is a test server, but also there no error...), so I'm bound to the live environment.
Is there a common practice to handle these kind of issues? (And if so, what is it?)
I know of the MAGE_IS_DEVELOPER_MODE, system log, exception log etc, but since on dev everything works fine, I seem to not be able to really debug a bug which does not show up... can I safely switch on the logging on a live site by the way?
Thank you all in advance!
Regards,
Tom
You can create your own log to see what is happening in Magento
Mage::log($datayouwanttosee, null, 'yourlogfile.log');
This will not break anything but will show you anything you want from that file. Once you load the page 'yourlogfile.log' will be in Magento's /var/log directory with the other log files.
Also make sure to turn your logging off when you are done otherwise the log could consume a lot of disk space.
You have better results if you contact OneStepCheckout support directly with this issue. Also verify that you ar using the latest version of OneStepCheckout
Totals however have sort ordering and this is available in Magento admin under system > configuration > sales > sales > Checkout Totals Sort Order
I am trying to determine how to debug an issue in Magento version 1.3.1:
When a customer uses guest checkout, the Authorize.net payment option is not available.
However, if the user revisits his cart and resumes guest checkout the Authorize.net option does appear.
We have now found that if Authorize.net is set to "all allowed countries" instead of "specific countries", then Authorize.net is available at guest checkout
We have not been able to upgrade Magento without breaking the integration into the parent site.
Thank you -- Tony
I had a similar problem with 1.6.0. Everything was working fine with the saved CC during testing, but when I shut that off and turn Authorize.net on, it ost the ability. So this is what I did to fix it.
I initialized the CC (Saved) back on, at the same time saved the config, checked it and sure enough, it came back on. So I then disabled the saved option again and then everything worked. My guess is when I turn off saved and initializedAuthorize an the same time, the settings were incorrectly written. Anyhow, worth a try if someone runs across the same problem .