My team is implementing PayPay Express Checkout (NVP) for our website. Before even initiating a transaction, we would like to perform a 'healthcheck' to confirm PayPal is alive and well. Looking over the API documentation, there is no obvious 'healthcheck' service available.
We are thinking of using the response from the SetExpressCheckout call to alert us of any system issues. Are we charged for every SetExpressCheckout call or for only completed transactions?
Making SetExpressCheckout calls and then abandoning the transaction, is this just going to anger PayPal?
Before we go too far into this, I'd like to mention PayPal APIs are in general quite stable, so such a thing shouldn't be needed at first place.
Having said that, are you seeing too many API failures? If so, I'd rather look into that (contact PayPal support) rather than using SetExpressCheckout as a way to do my own "health checks". Also, I suggest you to subscribe to such notifications at www.paypal-notify.com. This is PayPal website that allows merchants to subscribe for important notifications such as the one you are looking for.
Hope this helps.
Related
I wanted to ask if someone knows a possibility to pay make PayPal payments without user interaction. I am currently working on a Project, where we want to make PayPal Payments on demand without the user having to login to PayPal.
What I found was:
DoReference Transacations
Recurring Payments
The 2 Options would work for my purposes, since its OK if the user has to log in once. Since both of these methods are deprecated I wanted to know if there is another option.
At Cheddar we use the DoReferenceTransaction method with a "billing agreement" to enable transacting against a customer's paypal account repeatedly on any schedule for any amount. We have some documentation in our KB regarding how to create the billing agreement token via your app. Section 2.1 of that article would be relevant to anyone getting started with setting up a billing agreement for purposes of executing reference transactions. The rest of it is specific to Cheddar.
We, too, are aware that this method is officially deprecated. Our inquiries with PayPal suggest that it will be supported indefinitely. The new REST api does not support a modern equivalent. In other words, there's no new replacement for the DoReferenceTransaction method of Express Checkout or any alternative that enables autonomous recurring billing for variable transaction amounts on a custom schedule. If there was, we'd be using it. Practically speaking, there are countless implementations in the wild using reference transactions so I expect it would be impossible for PayPal to stop supporting it without an alternative (new) method.
FWIW, I recommend using a subscription management service provider like Cheddar. There are others that support recurring payments via PayPal account as well. Recurly comes to mind. Recurring billing and subscription management is complicated and it's made quite simple by these services. I recommend against using PayPal's native recurring payments as it is unnecessarily restrictive and once you start using it, you can't stop.
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.
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 need a help regarding paypal.
That is. Once I have logged in with paypal and made payment, Then for another payment no login will be asked, Direct payment will be done using paypal. Please comment your suggestions. Thanks in Advance.
You have a couple of options for this.
First, you could take a look at Preapproval, which is part of the Adaptive Payments platform. It allows users to create a Preapproval profile that your application can then use to trigger payments at any time without further approval as long as the payment fits within the guidelines of the preapproval profile.
Another option would be to look into Express Checkout with Reference Transactions. This would give you a little bit more flexibility and would be more in line what you're asking for, I think. Users would agree during their first payment with you to allow you to auto-charge this same account in the future. Then you would use DoReferenceTransaction to trigger future payments based on that "billing agreement" which is what it would be called that way.
I would recommend going with Express Checkout, and you might want to look at Digital Goods, too, which just adds some more functionality with quicker PayPal checkout in various ways.
It's all handled through a few simple API calls, so don't let all the info scare you.
My PHP class library for PayPal will make all of the API calls very simple for you regardless of which method you choose. Again, though, I'd recommend Express Checkout.
My company uses PayPal Payments Standard. Currently our checkout process works via the "cart upload" method and IPN to verify payment via PayPal's website. Should continue to use this method or if we should replace this with the REST API? From what I understand, the REST API is only to be used when the customer stays on our website for checkout, as opposed to going to the PayPal site and returning to our site after checkout. If this is true, I assume the cart upload with IPN method is still the best choice for us, since at this time we prefer to have PayPal handle credit card data. Am I understanding this all correctly?
The REST API is just a different way to integrate the payments programatically. The functionality is very similar and you'll be just fine sticking with what you're doing. No logical reason to spend the time redeveloping it if what you have is working fine for you. They won't be killing it or anything like that (at least not any time in the foreseeable future.)
As i see from a brief view, REST API for Paypal offers webhooks instead of IPN as a way to notify your system about payments and their progress. Each webhook describes which url gets notification request when some type of event takes place.