I'm trying to implement the PayPal checkout server flow described here and I'm a little bit confused about the role of the redirect urls required by the Create Payment REST API
With the PayPal checkout JavaScript components, I need to provide a onAuthorize hook in the JavaScript button initialization code like in the example on the page linked above. My understanding - and I've confirmed this in the sandbox environment - is that this callback gets called after user has successfully authorized the payment on PayPal and in this callback I'm supposed to execute the payment. This part is pretty clear and I've successfully implemented this. The confusion arises from the payload on the PayPal's Create Payment API.
This API expects a required parameter redirect_urls to be provided in the payload. Under this both return_url and cancel_url have to be provided. I understand from the documentation these URLs are where the user will be redirected after successfully authorizing the payment or if they cancel the payment.
In my tests in the sandbox environment, however, the user is never redirected to these redirect urls, as the "return" / "cancel" is handled by the callbacks provided to the button initialization. Now this leads to my question:
Despite this, is there any scenario where the user is redirected to these urls? What should happen if the user is redirected to these urls?
My concern is do I need to duplicate the on authorized / cancelled logic both in the JavaScript code and then upon entering the provided return urls?
The return and cancel url were important in cases where the PayPal experience is not in context (light box ) or if you want to take them to a completely different page once they approve the payment using continue or pay now or if you are using this in a mobile app where the checkout.js won’t work
With the checkout JS integration you don’t really need to pass the url as the experience is in context if that’s what you were trying to ask.
Related
I'm trying to implement the new PayPal Orders API, here is what I did:
Create a developer account, add an app name and then I have Client Id and Secret.
Use OrderCreateRequest to create an Order
Get approvel_url from the resposne->result->links
Redirect to this approvel_url and finish the payment
Paypal will redirect back to my website.
But I never got any thing from the PayPal testing account,Please, what did I miss?
Edit:
On No.4, when redirects to the PayPal page, somehow it only shows 'Continue' button on the page, not the 'make payment' button.
You are missing:
Display an order review page to the payer.
Capture the order with an API call, which (if successful) will return the transaction ID in the purchase_units[0].payments.captures[0] object.
On success, display a thank you/confirmation page.
Without the final capture API call, there is no PayPal transaction.
You are also still using an old integration method based on redirects, which is for old websites. Current PayPal Checkout integrations use no redirects. At all.
Instead of redirecting, make two routes on your server, one for 'Create Order' and one for 'Capture Order', documented here. These routes should return only JSON data (no HTML or text). When a capture response is successful, store its resulting payment details in your database (particularly purchase_units[0].payments.captures[0].id, the PayPal transaction ID) and perform any necessary business logic (such as sending confirmation emails or reserving product) right before sending your return JSON.
Pair those two routes with the following approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server
Here is my flow of the payment.
Create Payment and return Url for user to verify
Using above Url user opens Paypal account and accepts payment
After accepting payment Paypal returns to success url.
Execute payment (final stage of the sale)
My Question is if there exists any webhook triggered after step 2, before step 3. Right after user verifies payment in it's personal paypal page.
The reason to catch webhook is not to rely on success redirect url rather than use webhook.
The terms you are using do not match the keywords you've used here.
Are you working with REST APIs or are you working with PayPal Standard / Classic APIs?
If you're working with REST APIs, then the simple answer is yes, you should use the Webhooks to handle any automated processing. Specifically, take a look at the SALE Webhooks. That should give you what you're after.
If you're working with Standard / Classic, the answer is the same except that you would use IPN instead of Webhooks.
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 was trying to use the express checkout php api. Everything is working well in the sandbox environment. My question is regarding security.
After payment the sample code redirects to GetExpressCheckout.php?token=...$PayerID=.....; But after clicking "confirm payment" in my site and logging in to paypal account (did not confirm payment in paypal); I directly opened the same page in another tab, and it showed payment successful (which is not the case). Is there a way to prevent this or am I missing some thing.
I'm not following exactly what you're trying to say here.
The process needs to be...
1) Call SetExpressCheckout to retrieve your token and redirect to PayPal accordingly.
2) PayPal will return the user back to your ReturnURL if they confirm payment, at which point you can call GetExpressCheckoutDetails (optionally) and DoExpressCheckoutPayment to finalize the payment.
Not until DECP is completed does any transaction actually take place. The success message you're seeing probably came from GetExpressCheckoutDetails, which does nothing more than retrieve the buyer/order info so that you can finalize the payment on your site.
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.