I'm relatively new to payment integrations.
I'm just wondering if, it is possible for me to redirect customers to PayPal's checkout page by returning a url for the checkout page from the backend, instead of using PayPal's Smart button?
Tbh, I am having a hard time looking at their documentations. So please bear with me.
It can be possible, but it is an old integration pattern. For current web checkouts, pairing the smart button with a server-side integration is a superior UX in every respect. Here's the code to use for the approval flow: https://developer.paypal.com/demo/checkout/#/pattern/server
This way you never have to redirect away to another (possibly unfamiliar) site and back; your site stays loaded contextually in the background at every moment. Also it has an incline "Debit or Credit Card" button you can include as desired.
Related
I was reading today the Paypal Express Checkout w/ In-Context Checkout Docs and the feature looks promising in the scenario that you need to perform a purchase in place without page reload or redirection to another page, but the truth is that you still have to declare a returnurl and cancelurl in order to make it work.
Unless I am missing something, this takes the user to the same problem it tries to solve, leave the current page. An undesired outcome for the real-time web-apps. Is there a way to get some sort of call back without redirecting to another page? or this is not possible yet?
I'm in the process of developing a feature to accept payments in my website, and I already did it using a paypal button and IPN (a PHP listener to process data to a DB once the payment is completed, this one actually https://github.com/paypal/ipn-code-samples/blob/master/paypal_ipn.php, properly customized).
I never touched PayPal API and I wonder if I am missing something... I'm kind of new to this kind of development and I want to be sure I'm doing it right and not missing any obvious thing which might compromise the security of the payment or whatever... I already tested things in Sandbox and everything works as expected, but I am concerned about the API and I see many people using it...
So, am I missing anything?
Thanks!
What you've done is accurate and will work just fine so long as it's suiting your needs.
One potential security risk would be if you are not using a hosted button. Did you choose to "Save this button at PayPal" when you created the button? If so, you should see a hosted_button_id included in the HTML for the button. In this case it's protected.
If the button code includes individual parameters for things like item_name, amount, etc. then that code could be adjusted by people in their browser and then the button could be submitted with different pricing, for example.
You could check for this sort of thing in your IPN script and setup an automatic refund if the price doesn't match your database, but I generally try to avoid that sort of thing.
I prefer using the Express Checkout API instead. If you were comfortable getting IPN working with PHP then you should be plenty comfortable using this PayPal PHP SDK to integrate Express Checkout.
The three calls you'll need to work with are SetExpressCheckout, GetExpressCheckoutDetails, and DoExpressCheckoutPayment.
This documentation will cover the general steps and where those calls come into play, and that library will make each of those calls very simple for you.
Express Checkout will eliminate any potential adjustments users could make to code (because they won't be able get to the code at all unlike HTML) and it also has more advanced features and options that PayPal Standard does not have. Most importantly, the ability to force the "guest checkout" experience so that non-PayPal account holders can easily checkout using a credit card without any confusion.
They can do it with PayPal Standard, too, but depending on cookies set in their browser it may make the guest checkout option tough to find. Express Checkout makes it very prominent at all times, and generally results in increased checkout conversion rates.
There are 2 ways to integrate paypal with web site, Payment Button and Web Checkout.
The former seems to be easier than the latter, and we won't even to sign up an APP if we choose Payment Button.
Besides the difficulty of integration, is there any difference between them?
It's basically just HTML forms vs. web service API's.
The buttons are generally setup for a single item or for the PayPal cart, which I wouldn't recommend using. If you're going to be using your own shopping cart, you could actually just use the cart upload method, which is still PayPal Standard (html forms.)
If you are comfortable with API's, though, I'd recommend going with Express Checkout, which uses API's but still doesn't require creating an "app" in the PayPal network.
If you happen to be working with PHP you might want to take a look at my PHP class library for PayPal. It would make the API calls very simple for you.
I have implemented PayPal for my site, and i used IPN checkout. Currently when I press PayNow button on my site it shows PayPal Checkout page with following design http://c2n.me/iM28i8
But there is another PayPal Checkout page design (see http://c2n.me/iMwGZk), than the one I use. How can i switch to that design?
The second screen shot is new layout design that will be offered going forward . Currently it is not rolled out everywhere , so your buyers can see the different checkout page depending on the various factors like their country , ip adrees etc . This is only the change in design and will not affect the way PayPal process the transaction .
And there is no way to control the checkout design , it will be decided by the PayPal .
The second screenshot looks a lot like the payment page paypal has for mobile devices. are you sure that's not the mobile one?
We're developing an application that uses Paypal Express Checkout, and we're finding that we get two different landing pages. We're actually finding a problem that seems superficially similar to Can you force PayPal Payments Standard API to show credit card fields first?, but with a few differences:
Everything is fine with the sandbox, and we get exactly the appearance (credit card first) we want.
On the live site, about 50% of the time we get exactly the appearance (credit card first) we want.
Sometimes, we get a more "mobile-like" landing page, with the credit card stuff totally hidden in a "Check out as a guest" button, as shown.
This feels like a failing A/B test to me. We're sending exactly the variables in the question linked above, and as I said, all works fine with the older landing pages. I know there are also cookie issues, but in this case, we're seeing it even when Paypal is not able to identify an account and when cookies are cleared.
Does anybody know if there is anything we can do to work around this?
I can add code if needed, but the problem appears to be more data than logic.
I had the same question after I started to see users coming in from the 'new style' page.
I found the answer here:
Paypal express "order summary" page
I added the "force_sa=true" parameter to my Paypal URL:
https://www.paypal.com/cgi-bin/webscr?cmd=_express-checkout&force_sa=true&token=…
The new page is definitely weighted to appear more often on mobile devices. Without the parameter I get the new style page on a iPad after about 5 refreshes, with the parameter I can refresh as much as I like and never see the new page.
Obviously, PayPal will roll out the new page to everyone in the end, but this technique allows us a stop gap while we get ready for it ;-)
The screen pictured is PayPal's new checkout. It is only partially deployed at this point, you can think of it as A/B testing.
Regarding whether the customer sees "credit cards first", this mostly depends on whether they have a PayPal email stored in their browser cookie. If they do, the top "Log in to PayPal" section will be expanded, the email filled out, and they just need to type in their password and do about 3 clicks to complete the checkout..
If they do not have a PayPal email stored in their cookies, the bottom Create an Account or Pay as Guest section will be expanded. (If you want guest checkout, pass SOLUTIONTYPE=Sole in your initial SetExpressCheckout request).
The customer can always switch between the two expanded sections, it's just a "smart default" of sorts.
Try doing all your "credit cards first" testing in an incognito / private browsing window.