I have been trying to use paypal subscription and after redirect to paypal the interface were more or less like this (actually the subscription interface don't show prices only description)
After subscribe to a mockup app using Paypal, their developers manage some how to customize the interface like this
I was checking my profile in paypal looking for some trick, but there is not trick (at least that I could detect), I have a regular Paypal subscription
Any idea how to make something like this?
What you are seeing is the "old" PayPal checkout pages vs. the "new". They have been split testing these for a while now, so sometimes you will see one and other times you will see the other.
Related
Good day, everyone. I'm a bit stumped on this subject. I have a bit of experience with PayPal developer apps when it comes to subscriptions but this issue with donations is stumping me.
I would like to receive webhooks when a donation is made. I have created a new app in paypal developer dashboard, assigned it the webhook URL (a web app running on Python Flask) and while I have been able to successfully send and receive mock sandbox webhooks from the developer sandbox dashboard for testing so I know everything is configured to work. I just can't figure out how to now establish the live environment donations handling.
I have a business and a developer PayPal account. Within my business account (which I assume is the one that does live donation transactions), I have created a donation button. Logic would dictate that within this donation button setup, there should be a select option to specify the app who's webhooks these donations need to be using. But there is no such thing and PayPal's developer forum is deserted.
The general question is:
How does one set up a donation button to receive webhooks to a certain app or is that not how this works? Because I can have multiple donation buttons for various purposes, campaigns and configurations and I don't need webhooks for all of them. If I am forced to receive all donations, at least I see that there's a donation button ID which I can use to filter out donations coming from other buttons. But I can't even do that if I am not receiving donation webhooks at all.
Looks like for the time being to make this work I have to use Smart Buttons instead of donation buttons in Paypal. With smart buttons I can specify an app id I created in the developer dashboard and receive the webhooks this way.
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.
I'm new to PayPal and overwhelmed by all the possible approaches for integrating with PayPal.
As a start I want to implement one single subscription with monthly recurring payment. When the user returns to the site after fulfilling the payment, he/she will instantly be upgraded to "premium" member (digital product only - no shipping involved).
The first alternative I've looked into is the Express Checkout API, which looks ok, but is there any simpler way to do it?
Can I for example create a standard button (JS button or the form based), but still be able to verify the payment details when the user returns, using either the REST API, IPN or something else?
Any hints on best practices are appreciated.
Yes, there are entirely too many ways to solve this problem by now.
You can probably satisfy your requirements via buttons (aka Standard), Express Checkout (aka Pro) style APIs, or RESTful APIs, but there are a few gotchas to know:
First, PayPal has several products to do recurring payments; these products have functional differences and are tied to different integration styles. So (for example) PayPal's product called "subscriptions" (tied to Website Standard aka buttons) has different (and generally less flexible) capabilities than "recurring payments" (tied to Express Checkout) which in turn differs from "billing agreements" (tied to REST APIs, although the term "billing agreements" is also used in the express checkout recurring payments product). Oh, and there's another similar product tied to the Adaptive Payments suite of APIs.
Confused yet? Sorry. But it is important to determine whether the specific product you want to use will satisfy your requirements first before you do any integration, or you might end up redoing that integration work later (and potentially have to migrate customers, if you have already opened your business) in order to get access to specific features of another product later on. E.g., the subscriptions product has very limited ability for sellers to modify the subscriptions after they are set up. If that is OK, then great, use it -- it's simple to integrate. If I can oversimplify a bit: the Standard subscriptions product is the oldest and most limited; the Pro recurring payments is more flexible and mature; the REST billing agreement product is the newest, very flexible, but not yet as widely used; it may lack a feature you need today, but is the most likely to be continually improved going forward. I would not personally recommend the Adaptive product, although it also has its benefits.
Now, to your integration question: fortunately all these PayPal products can use IPNs. Unfortunately, IPNs are not instant. They generally arrive quickly (1-2 seconds) but delays can happen and it is quite awkward to be unable to process the customer. I would use IPNs only when shipping physical goods, not for immediate access to digital goods or in other cases where customers are waiting for a page from you. Fortunately, each of the other methods has a way to instantly determine the success of a PayPal action without waiting for an IPN:
Website Standard Payments will include GET or POST variables when it posts the user back to your site that will tell you about the outcome. If you use the Payment Data Transfer feature, these variables will include signature information so that you can post them back to PayPal & PayPal will verify their validity (so that a would-be thief could not fool you by engineering a post that looks like a PayPal success redirect).
The two API-based methods are even easier: the APIs themselves return all the information you need in the API response. So wherever in your code you make the call to create the subscription/agreement, if you get back a success then do your work to make your user premium.
There is the odd case of a user successfully paying and then getting "lost", as it were, e.g. the redirect failing/browser closing before they return to your site, or your site choking while trying to turn on the user. For this reason many people advise using IPNs, which PayPal will attempt to redeliver until you verify them back to PayPal. Not a bad idea, depending.
And of course you can call search & get details type APIs to get information about your transactions & agreements at PayPal -- although again, you will need to integrate with the right API that matches the product you are integrated with (e.g. Standard-based subscriptions won't show up if you ask the REST interface for billing agreements).
Hope this helps.
I plan to create a page on my website that lets others upload games and apps they've built, then sell them via PayPal. Please forgive me if this is a simple question, I've never used PayPal for anything other than purchasing things. I need the button to dynamically change who it's sending the money to. I understand that in order to split who the money is going to, I would need to set up a business account, but if I wanted the creator to keep all of the money they charge for their virtual goods, would it be as simple as changing one of the tags within the PayPal form?
I'm experienced in PHP, SQL and Javascript, so dynamically changing any of the forms elements wouldn't be an issue, but would the payment actually finalize?
Yes, if you're working with Payments Standard it would just be a matter of updating the business parameter with the email address or PayPal merchant ID of the person you want the money to go to.
This isn't the best way to do it, though, because people can see the HTML, copy it, adjust it, and submit payments that are for less than what you set the price at.
In order to protect that sort of stuff you could generate your button code using the Button Manager API, or better yet, go with Express Checkout and the Permissions API (or manually granting permissions) so you can make API calls on behalf of 3rd party users.
My PHP class library for PayPal would make this pretty simple for you.
Is there any known way (an api or something of the sort) that I could use to create my own user checkout experience for Paypal?
So, for instance, the user clicks my donate button which takes them to my donate page. I collect the needed user information and pass it securely to paypal using some auth method without ever redirecting away form my site or using their "Customize your Payment Page" (which is entirely not customizable enough for me).
I've looked through their myriad of api's but haven't found anything useful yet.
Thanks!
This can be done using the Direct Payment API. In order to use it, though, you need to have a Payment Pro account with PayPal.
If you plan to implement it with FuelPHP, then there is a feature rich, driver based, package here.