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.
Related
Trying to implement automatic payments via the Paypal Reference Transaction API.
Manage to make it work on sandbox but I noticed on the customer summary page, it refers to the payments as "preapproved payments".
Comparing it to services I used where automatic payments are enabled, the customer summary page shows them as "automatic payments".
Now I'm wondering if these are two different things. Or maybe the sandbox site has outdated/updated naming.
Are they the same?
Well, there are lots of different terms for these you might be seeing, but they are different things.
If you see preapproved payments, preapproval, billing agreement, reference transaction, then that's referring to having an agreement on file that allows your application to process payments on behalf of the user. This could be for any amount at any time, so you can build much more flexible apps with this sort of thing. It's also harder to get approved because it gives you, the app owner, a lot of power. Your app would be in charge of triggering payments when necessary.
Subscriptions, recurring payments, recurring billing would be referring to where you create a profile on the PayPal system, and their system takes care of triggering payments for you. These are more limited because it's a fixed amount that gets processed at a fixed interval.
This is my first time using the PayPal API so go easy on me.
The case I am trying to handle is as follows:
My customers can purchase software licenses that can either be one time payments, or yearly payments.
They can multiple products to the cart, and each product can have either one of the pricing plans mentioned above.
If I understand correctly, "payments" in the API handle one time transactions, and "billing plans" are used for recurring payments.
Is it possible to processes both in one call to the API? If not, is there a different way to achieve this?
Any suggestions would be greatly appreciated! TIA!
Not one API call, but you can do it in one checkout flow with multiple API calls.
For PayPal wallet payments (logging in to PayPal and paying) I would recommend using Express Checkout w/ Recurring Payments.
With that you would be using SetExpressCheckout, GetExpressCheckoutDetails, and then either DoExpressCheckoutPayment, CreateRecurringPaymentsProfile, or a combination of both of those depending on the products in the card and whether they need one-time payment or recurring.
The CRPP call will allow you to setup a recurring profile and include an "initial payment" which would be charged when the profile is created. This could be used as the one time payment if you want, and then you wouldn't need the DECP call.
Alternatively, you could use DECP to process the one time payment and then follow that up with CRPP to create the profile. There are advantages and disadvantages to the different methods depending on your business needs.
For setting up profiles with direct credit cards you'll need PayPal Payments Pro. In this case you would either use the same CRPP call mentioned above, but it would be used by itself and include the credit card details. Or, depending on the version of Pro they put you on, which depends on the version of PayPal account you have, you might end up using PayFlow instead.
If you're working with PHP this PayPal PHP SDK will make all of those API calls very quick and easy for you.
I know that's a pretty broad answer, but that's because it's a pretty broad question. :)
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'm going to offer my customers a selection of subscriptions to digital content. I want the customer to be able to add or delete subscriptions later, with as little hassle as possible.
It seems that if I use Paypal vault, I can collect the card information on the same subscriptions screen without multiple redirects and later change the monthly total without another checkout process or even customer sending approval to Paypal!
Does Paypal allow this? It seems too easy and also too permissive. Also, do I need to worry about PCI compliance?
Does anyone know a better way to do this (with or without Paypal)? I don't know how to use paypal recurring payments without a lengthy checkout if they ever change their subscriptions. Google wallet does not have subscription cancellation in their API! Several other alternatives only allow preset subscription amounts.
The CSC/CVV is missing from the examples here: https://developer.paypal.com/docs/integration/direct/store-a-credit-card/ which makes me think you cannot use the card at will. The customer is probably going to be asked for authorisation.
Normally your online payment provider needs to support recurring payments (installments, subscriptions). PayPal does, there's a specific API:
https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/installment_buttons/
For the customer it's one-off, then the card is billed, say, monthly.