I'm currently integrating our system with MiGS, I received all documentation and example code from Bank,
My issue is that they don't seem to be implementing IPN the same way PayPal does, they only request for a return URL to which the user is redirected after payment, however this URL cannot be used as an IPN listener on our side, simply because if the user closes the browser before being redirected, then our system will Never be notified of the payment,
Any help of how IPN is handled in MiGS?
Ok I just got answer from the bank that MiGS don't support IPN,so if the user closes the browser before being redirected back to our return URL, we can alternatively run Query DR , which would Query the status of the payment
Related
I maintain a PayPal integration which uses PayPal HTML Buttons and confirms payment using IPNs. This system has been in production for more than 5 years.
The system sets the cancel_return variable to a unique URL for each order. If this URL gets hit (i.e. if the customer cancels at paypal and gets sent to this URL), it first checks the session, to ensure the user hitting the URL is the same one who initiated the order, then cancels the order.
I noticed that several recent transactions have been cancelled even though the transactions at PayPal were successful.
The logs showed that customers are hitting the cancel_return URL - in some cases just after the IPN has been received, and in one case just before the IPN was received.
I found at least one way to reproduce this behaviour:
initiate the order on my site
complete the payment at paypal
return to merchant
use the back button to return to paypal
I then get a message that says "Your payment was completed. To continue shopping, please return to the merchant." One button is provided: "Return to merchant name".
Clicking this button takes the user to the cancel_return URL!!
PayPal's documentation for cancel_return says
A URL to which PayPal redirects the buyers' browsers if they cancel checkout before completing their payments. For example, specify a URL on your website that displays a "Payment Canceled" page.
Default — PayPal redirects the browser to a PayPal webpage.
My question is whether this is an intentional change by PayPal -- if so I expect it will break many sites -- or if this is a bug. I couldn't find a bug report at PayPal.
Yes, they changed the meaning of cancel_url, though they are not acknowledging this as a bug or an intentional change. This is definitely a bug in my opinion (as documented in the question above).
In addition to the steps above (reproducing using the back button), I found a customer click-trail in my server logs where the customer was sent to the cancel_url, without using the back button, soon after PayPal sent the IPN confirming their successful payment. I confirmed that the customer did not want to cancel and did nothing to intentionally cancel their order. Unfortunately I could not find a way to reproduce.
I registered at www.paypal-techsupport.com and submitted a ticket about this issue. After several exchanges, the end result I got was:
This is the information that I received from our engineer.
Its an expected behavior when the customer click on the back button, it will bring back to the cancel_url.
We would suggest you to do some modification so that the order is not being cancel when the customer go to the cancel_url.
With poor customer support like this, I will not be recommending PayPal to any of my clients in the future.
You can post it here and the PayPal folks can pick it up.....
https://www.paypal-community.com/t5/Merchant-Technical-Support/ct-p/mts
We are using SpiceLogic's BuyNowButton control with dedicated IPN_Notified event handler. Our payment processing logic requires buyer's redirection back to shopper site and we are interested to do it from IPN_Notified event handler after all verification there pass. We have noticed that Server.Transfer doesn't work there (gets suppressed) if you try to run it from inside event handler. Response.Redirect works as expected but raises non-braking exception "Thread was being aborted". Our question is: "Is there any known bad in redirecting buyer from IPN_Notified that way? Will it work in real PayPal environment as it works in our dev environment now?"
IPN happens completely separate from the checkout experience. A redirect will not work there because it's an entirely separate server session / communication. It's not anything happening in the browser.
It sounds like you must be working with PayPal Standard, so if you want the user to be returned to a specific page on your site after checking out with PayPal you can look into setting up Auto-Return in the PayPal account. Even with that enabled, though, there is no guarantee the user will make it back to your site because they could simply close the browser before it redirects.
If you want to guarantee the user always gets back to your site you should move to using the Express Checkout APIs instead of PayPal Standard. It will require more coding skill and working with web services, but it will give you much more freedom to do exactly what you want to do with your user experience.
In the SpiceLogic PayPal Control, the IPN_Notified event is completely a service type event, which is triggered by the PayPal IPN Notification service. The consumer of this event is a backend service from PayPal, not your customer. Your customer will never be redirected anywhere whatever you perform in your IPN_Notified event.
When PayPal IPN service calls your IPN URL, the IPN_Notified event is fired from your SpiceLogic PayPal control. But, PayPal does not care about that. PayPal simply calls that IPN Url and Post transaction data and then returns. So, if you issue a Response. Redirect, it will do nothing to PayPal IPN service. Response. Redirect is an instruction for the Browser, but PayPal IPN service is not a browser which will redirect.
If you want your user to redirect or convey a message, you need to use the PayPal_Returned event from the SpiceLogic PayPal Control.
In order to understand better the IPN and event workflow, please check these images.
I have a strange problem, I'm trying to figure out.
I'm using PHP and REST API.
This is the scenario:
1) Users press the checkout button
2) Payment is approved
3) Payment is executed
4) User is redirected to the completed purchase page
5) Few seconds later, Cancel URL of the transaction is called (like when users clicks on Cancel and return to merchant button, instead of approving the payment).
Out of about 100 transactions I had 3 wich manifested this way on all 3 the payment was actually made, and the funds where available. I have checked the server access log files and 2 of them were using ios 9.3.1 and one was an ios 9.2.1. How is this possible?
My guess is that they somehow hit the back button and then the cancel button, can this be the case?
My cancel URL contains a script which sets the order status to canceled, should I adjust the script to only set the status to canceled if the order wasn't previously executed.
Can anybody still cancel the payment AFTER I have executed the payment?
I think you should "trust" the IPN message sent by PayPal rather than the ok/cancel return url.
https://developer.paypal.com/docs/classic/ipn/integration-guide/IPNIntro/
The ok/cancel url should only be used to display the information to the user
Let PayPal know your IPN endpoint (the script which will receive the IPN GET/POST message). Once your script get called, update the database accordingly
Doing this way the user would not be able to screw up the transaction, you are guarantee to receive 1 IPN message, either it is an "transaction ok" or a "transaction error" message
Your issue seems to be similar to the question posted here.
From user2090027's response which was marked as answer
"We can overcome this by checking/maintaining the no of responses which we get after the payments are made on paypal.
We can maintain this using cookies on client end or on server using sessions or something else similar."
Hope this helps.
This is an old question but having built a PayPal integration myself I thought I'd add some info about why it happens.
If the user ends up on your "return" page after completing their payment and hits the back button, they'll get a PayPal page like this:
If they click "Return to merchant", they'll be sent to your /cancel URL. So if you get one of these and the payment has already gone through, you can show them the payment confirmation page.
My developer is trying to get the instant payment notifications for one of my web products to be sent to a secondary email, not the primary Paypal one. But no luck so far -it keeps getting sent to my primary email. I'd like some help on how to get it sent to a secondary email account?
Thank you
Your email address doesn't have anything to do with where the IPN gets sent. You basically have 2 options for configuring IPN.
1) Log in to the PayPal account that is receiving the payments, go into the profile, and then into Instant Payment Notification Preferences. Enable it, and add the URL to your IPN listener. This will now act as a default IPN listener so every transaction that hits your PayPal account will send an IPN to this URL.
2) If you include a notify URL in your button code or API calls this will override what you have setup in your profile. If you need to send IPN's for a specific button or API call to a secondary IPN listener you can just add that URL to the notify value for the request and that's where the IPN's will go.
If you need IPN's to hit multiple scripts you might want to take a look at this article I wrote awhile back about daisy-chaining PayPal IPN scripts.
I have an IPN handler, but it seems it isn't getting any IPN's from PayPal. When I hit the subscribe button, my payment goes through, but my IPN handler doesn't get any requests.
I tried invoking via Firebug's javascript console by
$.post('http://mysite.com/ipn', {'foo': 'bar'})
and I can see in my logs that the request is received (although my handler fails, as expected).
Debugging IPN is hard unless you follow the rules:
Check that the IPN URL domain resolves correctly to an external IP
Ensure that the URL is accessible from outside of your local network
Do not expect to use echo or print for debug - log everything to a file.
Create a "sandbox" account for a buyer and a seller so you can to test from both the seller and buyer perspective. Read the PayPal sandbox user guide.
Make sure you follow all the directions in setting up a sandbox test environment, including the addition of fake bank accounts and credit cards.