I am testing the PayPal REST API for subscriptions in the sandbox environment, and have noticed that, when going to the approval URL returned after creating an agreement, no price is shown under the order summary pane on the left of the page. A description is shown but no price/tax etc.
The plan id is passed to the call to create an agreement, which contains the information that I would expect to see as a user when approving the payment. Is this a bug or is there something that I am supposed to enable in the merchant account, or perhaps something additional that needs to be sent when creating the agreement? I've read other posts regarding this on stack overflow (although they predate the creation of the subscriptions REST API) talking about passing a transaction field, but this isn't valid in the subscriptions create agreement schema.
Your observations are (currently) correct. As REST API based Billing Plans are based on Express Checkout Recurring Payments, you're going to see a similar behavior.
Right now, there are two options:
You populate the description with more agreement details.
You pass a regular description and make sure the customer is aware of the billing terms before your execute the agreement.
Going forward, we're likely going to include this info in some later updates. I'm following up with that to make sure a user story is filed for this.
Related
I want to implement a pay as you go with Paypal, as I read the subscriptions API we need to create a plan and product, and as I understand it, it works based on the regular payments which obviously we don't want that we want if the user's budget is below a certain amount we recharge the user by a fixed amount again, can anybody guide me how to approach and implement pay as go using Paypal?
You are correct, subscriptions bill on a regular schedule whereas what you are describing is the ability to bill an arbitrary amount at any time.
That feature is called "reference transactions", or sometimes "billing agreements". It is not enabled for PayPal business accounts by default. To request the feature, the owner of the PayPal account should contact PayPal's general business support (note: not technical support) and explain the business need for this reference transactions feature.
If it's approved for the account, PayPal can then guide you on which API integration to use; potentially something like the newest v2/vault.
I've been searching Paypal's products and docs and I can't seen to confirm or deny if Paypal is a solution for what I need, so wanted to ask the community.
I run a web platform for creators to spin up websites. One common request is to create a page for them to sell their merch. I don't want to re-create Shopify/etc.. so have been telling them to go use that and link to their store from their website. But I'm wondering if there's an easy way to give them a very basic store experience using standard Paypal Buy Buttons.
My ideal approach:
Create a ShopItems model and users add items with price, description, shipping cost.
User adds their Paypal merchant ID
I generate a Buy with Paypal button that simply sends info to Paypal about the product being sold, how much to charge, etc..
I dont need any shopping cart functionality, and I dont want to have anything to do with the payment. I just want the end customer to feel like they're purchasing something (not sending someone $ via venmo), and have a place to add their shipping info, etc..
Currently, I see how a user can create accounts in their paypal account and then they're given a specific button for that item, but I'm trying to make this a little simpler where the user creates the product in my system and I just use Paypal for invoice/payment.
Would love any thoughts / ideas.
Integrate a version of PayPal Checkout: https://developer.paypal.com/docs/checkout/
Some sample demo code here: https://developer.paypal.com/demo/checkout/#/pattern/client (use the server version if you need robust payment completion notification -- this requires implementing two routes on your server, one for 'Set Up Transaction' and one for 'Capture Transaction', documented here: https://developer.paypal.com/docs/checkout/reference/server-integration/ )
If you know the merchant ID you're processing transactions for, this can be specified when loading the SDK: https://developer.paypal.com/docs/checkout/reference/customize-sdk/#merchant-id
Whether or not you specify a merchant ID on the SDK line, that same or some other identifier needs to be specified in the purchase_units payee object when setting up the transaction: https://developer.paypal.com/docs/checkout/integration-features/custom-payee/
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.
Is there any way to retrieve the transaction fee charged by Paypal using the REST API?
I've got a mobile application that makes a charge using the Paypal SDK, and then posts the transaction ID to the server. I'm trying to use this to get the transaction fee from Paypal.
Looking at the documentation, it looks like the fee should be returned as part of the details object, though it's not clear how to get this from the payment.
For example, if I get the payment using the following endpoint:
/v1/payments/payment/PAY-XXXXXXX
The response returns information about the transaction, including the amount and currency, but nothing about the Paypal fee.
I've also tried looking up the sale (/v1/payments/sale/XXXXXXX) but that doesn't return anything about the Paypal fees either.
Interestingly enough, I don't seem to be able to view this information either from the transactions grid in the web interface, but I'm sure this information was definitely available in the old version of the web interface (before the redesign).
Not sure if I'm missing something obvious here.
Unfortunately, despite being documented, it seems this hasn't been implemented. According to PayPal Merchant Technical Support, on 02/16/2015:
"Kindly take note that transaction fees will not be returned in REST APIs response and I am not being able to ensure whether this will be implemented in future."
I learned that fee tracking was a requirement for my company's PayPal implementation, and I ended up switching to SDKs as a result.
The details object of the amount object has a fee field, which when you look up the sale using the URL you mentioned above should be in each transaction in the transactions array.
This should return the value you are looking for.