I am working with paypal first time.
I have a product and I want to integrate paypal with it.
I want to achieve the following tasks :
Client comes to my website and select a plan,which is a monthly recurring plan.
Then client is redirected to Paypal for payment.
Client makes payment.
Return backs to home page.
I have gone through the documentation of paypal and I have the following questions.
What should I use REST API or Classic Sdk, as I want to create Recurring Profile,Work with EXPRESS-CHECKOUT and REFERENCE TRANSACTIONS.
I have customers all over globe and it is stated in the documentation that, for the customers in Germany and China , I have to use REFERENCE TRANSACTION.
Some where in the documentation of Merchant SDK it is stated that the classic API's will be deprecated, so is it a good approach to use Classic SDK
I also wanted to track the transactions(payment) made by user, so that I can show him the amount that is deducted in each month in his profile details.
Please suggest a feasible solution to my problem.
Thanks in advance.
Here's what I use. I went to Web Payments Standard and created a Subscription button. (I like the unencrypted variety, but you can encrypt if you want.) In there, you set the terms of the subscription, as well as where to post the IPN message. When the IPN message comes back, you deal with it. You'll get a subscr_signup at the start along with a subscr_payment. Then, on renewals, you'll get a subscr_payment again. What I like to do is store every verified IPN message in the database for my customer.
For handling the management of those subscriptions for things like tracking info, refunds, subscription cancellations, and voids, you'll need to use NVP API, which is a very simple API. If you stored in a database every IPN message with all those fields, then you should be able to pass certain fields of those to the NVP API in order to get what you need done.
If you're worried about longevity of the APIs, then don't. All they do when they deprecate APIs is stop giving you good docs on them. They still let those older versions run. If they didn't, there would be major upheaval on the web with web commerce products breaking all over the place. However, that said, if you want to prepare for the future, then get on the Braintree Payments API because PayPal bought Braintree and that's the future of their API.
Related
In Paypal, I m trying to implemen t a Auto payment system using paypal. Where user can save their card details then whenever the invoice is generated using card details invoice can be paid automatically.
I read the document of paypal but not found regarding that.
Please let me know how can I implement Auto payment system using PayPal.
There's quite a bit of information on the Subscriptions page, but most of that is a generic overview. However, there is link to the Integrate Subscriptions page that gives more links to specific API and SDK instructions.
Follow through the step-by-step information to get all this set up. It'll take a while to get everything correct, so definitely use their testing APIs so you aren't doing a bunch of tests on their production APIs and spending your own money doing it.
Once you get the subscriptions created and someone subscribed, PayPal does the rest. You just need to create the subscription and allow people to subscribe.
Also, PayPal keeps track of credit cards and other payment forms for you, so you don't have to go through all the PCI security procedures for storing that information yourself. That gets real involved and can cause you to get in serious trouble with fines and lawsuits if you aren't certified. It's much easier to use a payment processing gateway such as PayPal for this than create your own, especially since you are going to be using PayPal for processing the payments anyway.
I've been developing a marketplace type platform. Implementing PayPal Payouts seemed to be perfect for dealing with commissions. Especially being as PayPal will be handling all payments too.
I've successfully developed this part of the system. Inc. the webhook and verifying transmissions.
Now I wish to get my eBay sales info into my system. So that we can see it all in one place and have the system work the commissions out for those sales too. Having just invested the time into learning and implementing this PayPal API integration, it would be nice to use it for getting this data too.
So having tested the sandbox app thoroughly for the Payouts, I configured the live one. This is in my PayPal developer account where the app settings are. I've done nothing in my main Paypal account. Am I meant too?
My live webhook URL is just set to log all received data from PayPal. So I waited for a eBay sale and went to check the log but no data received? Am I misunderstanding this? The webhook is subscribed to all events.
The Drupal Commerce shopping cart I'm using already implements a IPN. Is it the IPN that I need to be thinking about? I'd prefer to not interfere with it to be honest, to keep future security updates safer. That said, I suspect there will be a way to extend it.
I guess the actual question is - what is the easiest way to get eBay sales info through PayPal?
Any help would be much appreciated.
eBay has their own system for that called Platform Notifications.
If I'm working with payment data, and I just need extra data from eBay, I will typically start with PayPal IPN / Webhooks and then use the eBay APIs within my IPN app to pull and push data as necessary.
Of course, depending on the scenario, you may decide to build out your primary solution inside of an eBay Platform Notifications app, and then make calls to PayPal APIs within that if you need to pull/push data.
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 am building website which requires customer to update paypal account.
Is there anyway to check the reality of customer's account?
When my customer fill out their paypal account in my site, I want them to be directed to paypal login page to login and paypal will return the result.
Does paypal api support this situation?
Pretty much any implementation of PayPal you choose would follow the flow you mentioned.
Payments Standard would allow you to create basic buttons or create an HTML form and POST directly to PayPal to process. It would send the user to PayPal for login and approval to complete the payment. The transaction details would include the payer status (verified or unverified) as well as the address status (confirmed or unconfirmed) and lots of other details about the order.
Express Checkout is basically the API version of Standard, but it's much more advanced and open to integrate in the way that works best for your site or application. In this case, some of buyer/transaction data is available during the process within your app through API requests and responses, and then you can also get to it via transaction details after the fact just like payments standard provides.
Another option would be to use Adaptive Payments, but if you're doing a general payment of any kind you probably don't need that. That's what you would use if/when you start wanting to split payments among multiple receivers within the same transaction, setup preapproval profiles, etc.
If you happen to be working with PHP my class library for PayPal will make the API calls very simple for you.
You could do what PayPal itself does when you register. Send them a few cents and have them tell you how many when they get it. The payment itself will fail if the account doesn't exist, and telling you how many cents proves that they own the account.
I have gone through the Paypal website, looked at their dozens of FAQS and documents, and still don't have a great idea as to how to integrate the Paypal Masspay API. I was hoping I'd have better luck on here :).
I have an app that gives users prizes, with an oracle SQL database that populates whenever a user redeems a prize.
Would I need to download the SDK onto my app, include the PayPal IPN, and call the MassPay API each time a user redeems a prize?
I have attempted to contact Paypal multiple times to no avail.
Not sure which aspect of your question is most problematic for you. I assume that you've looked at the concept diagram at
https://www.paypal.com/webapps/mpp/mass-payments
where the Excel worksheet is roughly analogous to a table's (or query's) worth of payees.
You would normally provide scripting code on your server/website that would submit that payee/amount list through the MassPay API calls against the PayPal website. If you only have one or two payees at a time, this is not the usual way to make a payment to your users (one-offs are generally Adaptive Payments API). It's not a downloadable app, though.
So is your app something the users download and interact with your site? If so, the correct place to put the code that faces PayPal (and actually transfers money around) is on your site's server. Not on the handset.
I finally reached a capable support member of the PayPal Team. The answer I got:
No SDK needed. All I need to do is set up an API call from my server to their server each time I want to reference a payment.