I am using omnipay package for my payment method in authorized.
I have two site on the same server, one is a live site that runs ssl and one that is for testing purposes only and do not run ssl.
Now, i dont have problem on paying in our testing site which it runs within our expectation. But, it seems odd in our live site because after entering my billing information, it returns an error that says:
An error occurred while trying to report this transaction to the merchant. An e-mail has been sent to the merchant informing them of the error. The following is the result of the attempt to charge your credit card.
This transaction has been approved.
It is advisable for you to contact the merchant to verify that you will receive the product or service.
Where do u think the problem lies? I really need help on this. Thanks!
This means the relay response URL used by your application is not returning a successful response to Authorize.Net in time (5 seconds). As a result Authorize.Net is assuming the page is not functioning and displaying that message.
You either need to verify the URL is correct, not error-ing out, and responding within a few seconds.
Related
Authorize.Net Direct Post for Magento
Getting below error.
An error occurred while trying to report this transaction to the
merchant. An e-mail has been sent to the merchant informing them of
the error. The following is the result of the attempt to charge your
credit card.
This transaction has been approved.
It is advisable for you to contact the merchant to verify that you
will receive the product or service.
This means the relay response URL used by Magento/your website is not returning a successful response to Authorize.Net in time (5 seconds). As a result Authorize.Net is assuming the page is not functioning and displaying that message.
You need to verify that the URL you provided is correct, reachable from outside your network, and responding in less than five seconds.
I'm using Server/InFrame integration, and according to Sagepay support, there are (rare) occasions when we get a notification about a successful payment (via an OK status), but this is then later failed. This can happen, according to Sagepay support, when they haven't been able to contact the bank properly.
I'm unable to find details about this in the documentation at http://www.sagepay.co.uk/file/1161/download-document/SERVERProtocolandIntegrationGuidelinesV3%200.pdf?token=0eZCcKj0tm33YeZ4gfrk4pHPaLClQnRcq3_vXsISjHI . The closest thing I see is in Step 12,
when SagePay sends batch files to the bank
If transactions are rejected, we correct any errors and resubmit them for you.
What happens, in terms of status codes sent to the notification url, in a case when this batch fails, or there is some other error after the "OK" is sent to the notification url? Is there any official documentation to handle this case, or similar cases when a payment is "OK", but then later fails?
Edit: I'm seeing that the simulator doesn't seem to handle this case either. Is there a way to properly test/simulate this case, when OK is sent, but then later failed?
The only reason you would receive a mixed message, such as Error/Failed on My Sage Pay but OK via Notification URL, is if an error occured during the notiication which returned an error/invalid response.
If the notification response via the Notification URL is interrupted i.e. browser refresh/closed etc Sage Pay may pick this up as error after the authorisation from the bank has been received as OK. We will then send Error via Notification URL to confirm the transaction has failed.
We'll send the notification several times until we receive a successful response/handshake from you in which you confirm the Status, StatusDetail and RedirectURL.
This scenario does not occur often however if you are able to provide a TXID example, our contact details can be found via http://www.sagepay.co.uk/contact, within 72 hours of the transaction being posted, we can investigate the reason for failure against the transaction logs.
Sage Pay Support
As a team we're currently investigating a strange occurrence. It doesn't seem to apply to all orders by any means, but it is affecting a large number of customers based on the logging we've added to the noItems.phtml page.
Please note: I'm not really expecting an answer as I assume this is a problem we have to solve ourselves based on addons, and our server configuration (three servers for loading balancing). However, I am looking for possible ideas and/or whether this is something somebody has come across previously.
What we've done so far, and what we know:
User enters their card details in the SagePay iFrame;
User purchases an item via SagePay -- order is successful;
Some users are sent back to the success page;
Some users don't see the success page (phoned to confirm a handful) but instead return back to the empty basket;
We're still investigating, but we find it ever so strange how a user would return to the empty basket page. We've added logging to the noItems.phtml and we can see that some users are getting assigned another session ID after a successful transaction. This seems to be the problem, but why the user is being assigned another session ID after a SagePay payment isn't easy to comprehend.
Has anybody else experienced a similar issue with SagePay/Magento? And if so, what steps did you take to solve?
Our Sage Pay Support team would be happy to look at the transaction logs (within 72 hours of the transation being submitted) and help you determine the reason for the failed transactions on 0845 111 4455 24/7.
You reply to the Notification URL when you acknowledge receipt of our response. You have 20 seconds to response. You need to send the Status (OK, Error or Invalid), Status Detail and Redirect URL. We then send the shopper back to your Redirect URL.
A few suggestions would be:
If we can't reach your Notification URL, check you have ports 443 and 80 open. Check you don't have a DNS issue.
If you are receiving the notification from Sage Pay to confirm the status of the transaction via the Notification URL. Check the information you are sending is in the correct casing, that it is not empty data and that your website is not spooling and check whether the success/failure URL is a valid landing page.
All our system needs is the Status Deatil, 'Status = ' and 'RedirectURL =' fields with the appropriate values assigned, separated with Carriage-Return and Line-Feeds (as specified in the protocol) . Nothing else is required. The response you send should also be text/plain message, not text/html or any other MIME type.
If the customer is being sent back to an empty basket, check whether your website is doing a job in the background such as writing to a databse, preparing confirmation emails to the back office before sending the customer to the payment page. Test whether your server can handle the amount of transactions coming through from Sage Pay. Or are you truncating the NEXT URL?
Regarding a session ID, each transaction is assigned a unique Sage Pay ID called a VPSTxID which is used to identify the transaction. We can take a look at the transactions you are referring to if you are getting several session IDs to discuss further if you would like.
Sage Pay Support.
Check the action that pushes the user to the success page on successful purchase. Maybe its something like target _parent. Maybe its something where its trying to load the success page in the iframe. Or maybe its timing out on sagepay when trying to redirect.
I'm not typically a web developer, but I'm a decent enough coder that I felt comfortable accepting a proposal from a friend to develop his brother's small business website. I'm nearly finished and I've been using CodeIgniter, which has been a huge help and was easy to jump into.
They have a handful of products they'd like available for purchase via the site, their preference was Auth.net (which I have no previous experience with), and their host does not support SSL (nearlyfreespeech.net), so I decided that Auth.net's SIM was appropriate. If I test SIM outside of the CI application with a relay response page which simply spits out the available transaction details, everything goes as expected. If I try it with the relay response page set to a CI controller/method which simply echoes a string, Auth.net displays the following 'error':
An error occurred while trying to
report this transaction to the
merchant. An e-mail has been sent to
the merchant informing them of the
error. The following is the result of
the attempt to charge your credit
card.
This transaction has been approved.
It is advisable for you to contact the
merchant to verify that you will
receive the product or service.
My initial thought was that perhaps the rewrite rule I set up to circumvent having to include the index.php front controller was the issue, so I tried including it in the relay response URL with no change. I should also note that the controller in question implements a _remap() method, but the relay response method shouldn't be affected by it as it doesn't match it's regex.
Any insight(s) would be greatly appreciated.
This error occurs when your script doesn't respond within a specified amount of time. It also is displayed if anything other then a 200 success message is returned. So basically there is an error in your relay response URL.
You need to test this first by pulling up the page directly to see if it works and returns the proper header response. Then you can test it by sending a simulated POST response to it and see if it also responds properly. If those work make sure the script isn't taking too long to respond. If it is there probably are ways to optimize the slow page to give the response in the appropriate amount.
I have set up payment processing through Authorize.net (actually through a reseller) and I am able to successfully perform Test transactions. However, when I perform real transactions, I get a Rejected transaction. When I check the transaction in the authorize.net account I see "General Error (Request rejected by FDC Omaha - Wrong Merchant Type). I assume this is some sort of configuration problem between First Data and authorize.net or me. However, I have no way of telling exactly what the problem is. Authorize.net told me to contact my MSP and the reseller is saying there is nothing they can do to fix the problem (I find it hard to believe.) Is this a setting on my side that I can fix? Help!
You must contact your merchant account provider to fix this error. I've seen this error message several times with our customers at www.authnetscripts.com.
The error indicates a mis-configuration with the processor.
Thanks!
We got this error recently on one of our sites, so we followed the advice to call the merchant account provider.
We called and they told us that sometimes you can get this error because of the type of card (MasterCard, Visa, Discover, AmEx, etc.) that is being used. We tried a different type of card and it processed correctly.
Hopefully that helps someone else who runs into this same problem.