How do I complete purchase with Omnipay Sagepay using sagepay server (inframe) - opayo

I can't seem to find an instructions for Omnipay\SagePay, and am struggling to complete the purchase when SagePay posts to my notification URL.
Can anyone provide info, or point me to where I can find out what actions and parameters are needed for the notification URL to complete the purchase please?

Sagepay is tricky because the notification part is done by Sagepay and not by the client, so make sure you give an Internet accessible notification URL (that was my first mistake). Here's some example code (using Laravel) to process a Sagepay payment:
public function postProcess($transactionId)
{
//get the order details from somewhere
$order = $this->order->findByTransaction($transactionId);
$response = $this->gateway->completePurchase(array(
'transactionId' => $order->transaction,
'transactionReference' => $order->reference,
'amount' => $order->total,
'currency' => $order->currency,
))->send();
if ( ! $response->isSuccessful())
{
$response->invalid(URL::to('checkout/problem'));
die();
}
$response->confirm(URL::to('checkout/complete/'.$transactionId));
}
As you can see it's quite a bit different from the other examples as you need to call completePurchase() and then separately send a response to confirm.
Let me know if you need anymore help.
Cheers

From here you can either read more about the integration methods or scroll to the bottom of the table to download the Server documents. Our kits are available for you to download.
Are you getting an error message when Sage Pay is trying to reach your NotificationURL? Or, are you getting notification that Sage Pay has contacted you via your NotificationURL but you are not able to redirect the shopper to the RedirectionURL, the landing page to tell the shopper about the status of the transaction?
Few points to check for a 5006 error (Unable to redirect to the vendors website. The vendor failed to provide a RedirectionURL).
Is the SecurityKey matching?
If the transaction is not showing in My Sage Pay, provide Sage Pay with the TxID so that we can check the logs (if within 72 hours)
is the NotificationURL an http or https URL? consider html5 issues
if Sage Pay can't reach the NotificationURL, check that you have the ports 80 and 443 open. Have you received any attempts to the NotificationURL before?
check not a DNS issue
check your website is not spooling / not an issue with hosting company?
make sure Status=OK rather than Error or Invalid
Can you provide more information so we can help further?

Related

PayPal REST API not returning recurring payment information in laraval

I am working on Paypal webhook (subscription) section to insert recurring payment information into the database. I have done coding based on the link "https://jslim.net/blog/2018/01/22/PayPal-Rest-API-with-Laravel-5-and-Angular/" but Paypal webhook always return “payment_status: Pending” on sandbox image and its not inserting recurring payment information into the database (insert option added in PayPalController - function webhooksPaymentSaleCompleted ).
I think the problems related with routes/api.php file but I can't figure out what exactly is going wrong.
Another URL that I have referred and tried was "https://github.com/supermavster/PayPal-PHP-SDK"
Laravel version 5.8
paypal/rest-api-sdk-php: "^1.14"
Please suggest a feasible solution to this problem.
Thanks in advance.
Verify that the sandbox account's email is confirmed, by logging into the sandbox business account receiving the payment and navigating to: https://www.sandbox.paypal.com/businessprofile/settings/email
Resend the confirmation message. Open the message via https://developer.paypal.com/developer/notifications/ , and confirm the sandbox email.
The v1 PayPal-PHP-SDK is deprecated and there is no reason to be using it for a new integration. Use the v2 Checkout-PHP-SDK for payments.
You'll need two routes on your server, one for 'Set Up Transaction' and one for 'Capture Transaction', documented here; https://developer.paypal.com/docs/checkout/reference/server-integration/
The best approval flow to pair it with is https://developer.paypal.com/demo/checkout/#/pattern/server

AuthorizeNet Omnipay Error

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.

After a successful Magento payment via SagePay, the customer is redirected to the empty basket page. Why?

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.

Why is Authorize.net throwing an error when my relay response URL points to a CodeIgniter controller and not otherwise?

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.

PayPal Orders Cancelling Automatically In Magento

I have this weird issue in Magento when someone places an order using PayPal Express Checkout. Every so often an order will come in and then the order gets canceled a few seconds later. The comment that is left is as follows:
Canceled order online. Amount: $59.23. Transaction ID: "XXXXXXXXXXXXXXXXX-void".
(ID blanked out just in case)
Now our customers are swearing they did not cancel their orders and when we ask PayPal they say it is a problem on our side.
Has anyone heard of this issue and do you know of a fix? I am running Magento Enterprise 1.8.
I've run into a similar issue. I tracked it down to those users who checked out with PayPal Express and do not have a PayPal account. The issue and the fix appear here:
http://www.magentocommerce.com/bug-tracking/issue/?issue=9894
The face that all users do not encounter the error may be related to the with/without a PayPal account status.
Integrating Magento with PayPal Express (not PayPal standard) the users can buy our store's products.
However, there are two different situations:
1) If the customer has got a Paypal account, he will be able to finish the buy process without issues.
2) However, if the customer hasn't got a Paypal account, or if he doesn't want to use it, and prefers to buy the products using his credit card without use the PayPal credentials, then the process will finish with the following error:
"This payment cannot be processed using your paypal account at this
time".
The problem is the seller will receive the money, but the customer will think just the opposite.
This issue has been discused and confirmed with PayPal support team.
The real issue is during the buy process, the "DoExpressCheckoutPayment" PayPal's function is called. However, when the buy process finish with this error, a parameter called "successpageredirectrequested" is set to "true". This flag indicates whether you need to redirect the customer to back to PayPal after completing the transaction. However, this is an obsolete PayPal's behavior, and should't be used.
As Magento is using this parameter's function, when he tries to redirect again to PayPal (that's what "successpageredirectrequested" set to true is doing) PayPal will return this error.
We can fix it making a little change in Magento's source code, at app/code/core/Mage/Paypal/Controller/Express/Abstract.php
Just changing the function "public function placeOrderAction()".
Look for the following code inside this function:
// redirect if PayPal specified some URL (for example, to Giropay bank)
$url = $this->_checkout->getRedirectUrl();
if ($url) {
$this->getResponse()->setRedirect($url);
return;
}
$this->_initToken(false); // no need in token anymore
$this->_redirect(?checkout/onepage/success?);
return;
}
We just need to comment the "if", just like this:
//if ($url) {
//$this->getResponse()->setRedirect($url);
// return;
//}
That's enough to fix the issue. However, this is not a current fix, and this should be reviewed by Magento's programmers just to fix it in the Magento's new versions.

Resources