I had a working PayPal flow for buying subscription using PayPal buttons. User had to click the button, PayPal window opened, after filling all the data, PayPal window disappear, onApprove hook was fired and I can handle the rest in my code.
But for few days, flow changed, and now, when user enters correct data, PayPal windows is not closing by itself, but showing information what user bought, who is the seller, how to remove subscription. onApprove hook is not fired, so I can't handle the result. All user can do, is close popup by himself, but then onCancel hook is called, instead onApprove.
Payments are proceeding correctly, following webhooks are handled by backend etc. I just don't know what happened to my onApprove hook.
It was a paypal bug which has now been fixed
Related
I'm trying to implement the PayPal Subscription API but I'm not sure about the process flow.
I use the react-paypal-js package to generate the subscription button.
The way the users are created on my website is only through the Paypal subscription.
The process is as follow:
The user choose a plan and click on the subscribe button
The PayPal window open and the user follows the subscription process on Paypal
The user is redirected to my website
Using webhooks or with the onApprove callback, I receive the newly created subscription, create a user on my website with the Paypal email address associated with the subscription.
It all works. My problem is that I need to check, before accepting the subscription, if I already have a local user with given email and in this case, I don't want to accept the subscription (as I would then have 2 subscriptions for the same user) and display a message saying that their is already an active (or suspended) subscription associated with the given email.
As far as I can tell, when the onApprove is called or the webhook is called, the subscription has already been processed and activated.
Thanks!
You don't have to design a system in which the PayPal email used to make the payment, and the email of the user used to log into your site, have a 1:1 relationship. Instead you can have the user log and create their account with you first (as they will always need that to manage something subscription-based) and then you will know there is no subscription associated with that user before displaying the PayPal Subscribe button. Then they can pay with any PayPal account (might be the same email, might be different)
As far as I can tell, when the onApprove is called or the webhook is called, the subscription has already been processed and activated.
That is the default behavior, yes. Per the above it shouldn't be ncessary, but you can change the subscription to start in an inactive state, and show a final review step on your site that will activate it via API. This is controlled by setting application_context -> user_action -> CONTINUE (vs default SUBSCRIBE_NOW). See the API reference for subscription create, and you would of course need to use the subscription activate API call as a final step after confirmation.
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.
After adding stuff in shopping cart, clicking some Pay Now with PayPal button, and successful PayPal payment (PP or CC), it is logically possible that a user stays on PayPal website, if for example the Auto Return option isn't activated (or it is but it doesn't work because the user is a guest user without PP account)
The user can return to the site by clicking a link, but doesn't have to. My question is: if he doesn't, how will the site owner be aware that the user paid so that he can now send the items by post? That the site owner gets informed of being paid seems elemental to me, so I find incomprehensible that such elemental thing be left to some obscure Auto-Return option.
Please can somebody explain this to me?
This is a common challenge with any redirected payment gateway, and it's the reason most (if not all) of them implement some sort of asynchronous notification that a payment has been completed. In PayPal, this is the Instant Payment Notification (IPN). You must setup on your site either a generic IPN listener that you link to from your PayPal account profile settings or you can create a more targeted IPN listener specifically for your transactions and use the NOTIFYURL (or related) parameter in the form or API request you use to redirect to PayPal to send IPNs to that listener.
In my integrations, I never perform any order update or transaction logging when the customer returns from the site, preferring instead to wait for the IPN that I can validate and ensure came from PayPal as opposed to a spoofed return from someone trying to hack my checkout process.
For more information, see the IPN documentation: https://www.x.com/developers/paypal/documentation-tools/ipn/integration-guide/IPNIntro
Paypal provide IPN for this purpose through which we paypal send request asynchronous to your site and you can perform whichever action you want
I think the point may have been missed here. Or a problem does exist. If the purchaser uses CC, even if you have IPN set up and it works, but if the purchaser uses CC and does not click a button on the last page, which is not presented when using PP account, it is possible for the funds to go through, but no IPN, and so your website is unaware of the purchase. This last page, is an extra page that CC user gets after the page with the Pay button on it.
In this state, you can even go into IPN history, and the IPN is there, says it is sent, but it hasn't been. It does not get sent until after the purchaser clicks the button on the extra page and then they are taken to the auto return page.
So I'm working with Express Checkout and everything seems to be going well. I noticed a strange thing though, in about 1 out of 1000 payments, the routine is the following:
All good during SetExpressCheckoutPayment, sending to PayPal
PayPal processes the payment, returns the user to to my RETURNURL
I charge the user with DoExpressCheckoutPayment and get the success response, yey!
A few seconds later PayPal sends me an IPN with a successful payment, cool!
Around 30 seconds later, my CANCELURL gets hit with that same token
Now that's confusing. Checking the transaction with GetTransactionDetails says Completed, but my user's purchase is set to Cancelled. One way would be to simply ignore a CANCELURL hit on successful transactions, but I'd really like to know why is this happening.
Have you ever noticed the same thing happening on your site? Any idea what the user workflow might be to generate such a glitch? Any other workaround ideas except ignoring calls to CANCELURL after a successful payment?
Thanks all!
I have noticed sometimes the mini browser is not faded when you click on "pay now" button (see Express Checkout for Digital Goods : can click several times on Pay now button).
So maybe your users click on pay, nothing seems to happen for them so they click on cancel link.
I'm looking for a way to prevent this (clicking on "cancel" or twice on "pay now"), if you know how...
I'm implementing a simple Buy Now button and I'm using IPN (not PDT) to verify the transaction.
A thing that bugs me is that I don't understand how come only after I set the notify_url field to the button I also get the transaction variables to the success URL, as GET params. It would seem normal to be the other way around.
Since the user could or could not choose to "return to the merchant's website" there's not way I should rely on that data. It does however seem to be identical to the one sent to the notify URL.
Some clarification would help. Thanks!
I know what you mean, after the user has finished paying and chooses to return to the sellers website (button in paypal page) they are redirected to your thankyou page.
I don't think it used to do this back in 2009 but now paypal will issue the redirect with all sorts of parameters in the url query string.
I'm just ignoring this information and relying on the backend IPN post which is verifiable by paypal
In my previous experience with IPN, I defined the location of the notify URL in the control panel. Once the payment is processed, PayPal sends a POST notification to this URL independent of any user behavior.
In any case, even if you define the notify_url parameter in the button, I believe PayPal will still send the payment notification seperate from the user behavior - they spawn a new process to send the data. As to why they are using a GET rather than a POST, that is odd behavior. However, in your IPN script you should still have logic that verifies the call with PayPal before you continue processing.