I've had a look at the preapproval API which looks kind of like what I want but not quite.
I need to mimic the way Kickstarter works fairly closely; users are sent to the Paypal site where they sign in and agree a payment then on a certain date the payment either gets taken from their account or, if some conditions aren't met, nothing happens. I know Paypal are 'funny' about some uses, but actual goods and services are for sale so I think it should be OK.
I need many people to be able to contribute to one larger payment; I don't know if there's a way of setting up a something like this inside of Paypal itself or if all the logic should be kept separately and then the Paypal payment triggered on a certain date?
I have answered two questions on quora related to this that you might find interesting about PayPal's recommended approach for crowdfunding projects like this:
http://www.quora.com/PayPal/I-want-to-use-Paypal-for-my-self-hosted-crowdfund-campaign-but-I-heard-they-might-close-my-account-if-theres-too-much-money-coming-in-is-there-a-way-to-fix-this
http://www.quora.com/PayPal/Is-paypal-better-for-crowdfunding-than-amazon-payments-why-or-why-not/answer/Praveen-Alavilli?snids=55404046#ans1382191
Let me know if you have any questions that I can help with.
Related
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'm really having trouble finding out how to set this up. Their documentation is horrendous at best. I called Paypal and told them what I need:
have my own custom shopping cart
client doesn't want to pay monthly fee
I was told that I could use Website Payments Standard to send my cart contents and the user can choose to sign in/pay or simply pay by CC without an account. Every link on their documentation sends me to the silly HTML button creator. I don't need hand-holding through the coding, I just need to know where I can find the proper documentation. I don't want Paypal buttons that send customers to a paypal cart page every time they add something.
https://cms.paypal.com/us/cgi-bin/?cmd=_render-content&content_ID=developer/e_howto_html_cart_upload
This is what I was looking for. It only took 3+ hours to find, so congrats to you Paypal. You've stolen my money in the past, now you've stolen my time. Hopefully this helps someone else who was looking for the same thing.
Thanks! I'm looking for a way to implement paypal in my java (spring) server so my clients (or I) can easily setup their webshops. I totally agree that implementing PayPal in a web application should be simple and in reality is a total mess.
So thanks a lot for posting this here, I guess you also saved me some additional time!
Best wishes,
Jochen
Is paypal a suitable system for handling event ticket payments. All I want to do is create a page with event details, a list of hOw many tickets are left and a secure payment handling. Systems like eventwax seem to charge for use of there system and then paypal charges you too. I just dont get why people are paying twice. Also does anyone have any other recommendations for similar sites like eventwax
Google Checkout lets you do something that will work for you. Basically you create a Google Docs spreadsheet that follows a special format and contains the items that you sell and the quantities remaining. Then, you can make an HTML button that you can embed in your page. When a user clicks the button, it processes the selling of a specific item from that spreadsheet. Google handles everything else automatically - it subtracts one from the quantity field in the spreadsheet, processes the payment and sends you an email with the purchase and shipping details. Little to no programming required.
Of course, this can't work with PayPal.
First off, paypal comes in many different flavors. From the simple they host the order form and process payments way on up to all you do is pass them the credit card info and charge amount and they process it.
With that in mind I don't believe they support selling a limited quantity of items. This is something you would have to provide with your site.
Which leaves us with: are you asking a "how do I code this" type of question or something more general. If the former then please provide language and what you have so far. If the latter, then you might try at http://webmasters.stackexchange.com
Now regarding eventwax charging for usage, that is a perfectly legit thing to do. They are providing a service which allows people to sell a limited number of things, ensure that those things aren't over sold (which can be difficult depending on your db transactional experience), and handle payment processing.
All said and done there are really several companies which will get a piece of the action so to speak. Paypal is one, the credit card companies are another. If you are using paypal's payflow pro gateway then there is at least two other companies involved: your bank and the transaction processor themselves.
Which leads us to why people pay companies like event wax. Quite frankly, it's easy they don't have to screw around with programming something, and it works right now. There's a lot that can be said about doing things this way. Usually you just include all of this into the cost of doing business.
I'm trying to integrate a payment mechanism to my site. The scenario that I need is not trivial and can be explained by the following example:
User pays upfront for a subscription program (i.e. receiving Netflix). User is able to make changes to the subscription (i.e. change number of movies checked out each time from 4 to 2)
User is able to buy additional one time purchases via the provider's site (Netflix) supplied by 3rd parties. These items (i.e. popcorn, snacks) get billed to the same credit card as the subscription without having to go through the process of resubmitting the credit card information.
Of course, my site takes also a small fee for the transactions :-)
I was wondering if this is supported by PayPal, Google Checkout or someone else.
Thanks.
The Paypal api can handle all of those processes.
I seem to have dropped the ball on what kind of answer you wanted so I'll leave it at that.
If you have some feedback, more direct questions I will try to answer as much as I can
--
The money would best go through you first, unless somehow you can convince your customers its normal to bill them per item. Also if they pay by credit card you should only bill them once as you would incur fees on every payment. I don't know of anyway to bill once but distribute the payments.
As for the paypal docs..
Very good resource, there is also some sample code for most major web languages
Also this will get you started if you don't have a developer login
Their developer support is also pretty good. One thing a lot of people seem to screw up when starting out with the paypal api is not setting the latest version in the configs so don't forget to update that to the latest release. :)
Disclaimer..
Yea I know there is a lot of bad press about paypal and crazy stuff happening, but they do get the job done most of the time, its not my fault the customers love to use it.