Paypal REST API Adaptive / Multiple Payments (change payee) - paypal

I've just started looking at Paypal's REST api. One thing I can't seem to see is a feature paypal call Adaptive Payments. This allows me to register my app with my developer account, but not be involved in the actual payments. e.g. my app allows my users to accept payment for their services, which they sell through my app.
I have been through Paypals REST API documents. I have worked out how to complete a payment, but all the transactions get sent through to my developer paypal account. I can't find where i would change the receiver details, i.e. the seller, to allow payments to be sent to a different paypal account.

Ok, after some extensive googling, I managed to find the answer here
This general model enables us to easily add support for variety of payment models in the future (Parallel, Chained, etc). The Payee could be a funding instrument (like a Credit/Debit Card,) or a PayPal account (wallet) itself. The Payee could be set explicitly if the Payee is not the same as the Payment Facilitator ( in this current release we only support the case where the Payee is same as the Facilitator) so this is not currently required.
So looks like a payee is just added to the transactions array, but this is not currently implemented as of the date of this answer.

As of January 3rd 2017, PayPal has now added the ability to set the payee to anyone you wish.
Notice the new payee object below:
{
'intent':'sale',
'redirect_urls':{
'return_url':'http://localhost:3000/process',
'cancel_url':'http://localhost:3000/cancel'
},
'payer':{
'payment_method':'paypal'
},
'transactions':[{
'amount':{
'total':'10',
'currency':'USD'
},
'payee':{
'email': 'payee#test.com'
},
'description':'My amazing product'
}]
}
However, there doesn't seem to be an ability to have multiple payee's.
Additional info here: https://devblog.paypal.com/setting-payee/

Related

Add shipping cost after user authorizes PayPal payment

I'm using PayPal Checkout, which isn't well-documented but doesn't support automatically adding shipping costs in the account dashboard as far as I can tell. I need to charge users different amounts for shipping depending on their location, which I don't receive from PayPal until the user authorizes a payment. Without re-authorizing, how can I charge an additional fee for shipping? I saw this behavior implemented on this site recently while making a purchase – I authorized a payment using what appears to be PayPal Checkout, after which I was able to select a shipping method (some of which cost up to $30 extra) and it seemed I was able to complete my payment without reauthorizing.
I haven't found anything in the PayPal Checkout documentation or by inspecting the object passed into onAuthorize that seems to expose this functionality. I did find a PATCH /payments/payment/{id} endpoint in the docs for the Payments API, but I have no idea how to access this from the PayPal Checkout flow on my website, nor whether my site is considered a "Third Party Provider in the context of PSD2 regulation."
How can I add a shipping cost to a payment after authorization using PayPal Checkout?
You can find more required info here :https://developer.paypal.com/docs/checkout/integration-features/shipping-callback
paypal.Buttons({
onShippingChange: function(data, actions) {
console(data);
}
}).render('#paypal-button-container');

Paypal Rest API Payment or Braintree Payments

I used the Paypal NVP API (Express checkout) for a long time and it worked fine. I'm now developing a new project and wanted to use the 'new' Rest API that Paypal recommends for new projects. I, however, find the documentation rather imprecise at some points and often contradictory.
I'm using their sandbox to test the payments and I noticed that the payments work fine, except that once I log in to the Paypal Buyer account, I can only select the PayPal balance to pay.
Is this a limitation of the Rest API? I want to clarify that I am based outside the US and I do not want to accept credit card payments on my own website (well, if there is no other solution, I would accept it). I'd rather have the user get redirected to the PayPal page and provide his credit card information over there. I do, however, want to give the option to the user to at least select from PayPal balance or credit card. (As I'm used to from the NVP API)
UPDATE
In the meantime, I've done a lot of additional research. On the PHP SDK page, they've added the following notice:
Important: The PayPal REST API no longer supports new direct credit card integrations. Please instead consider Braintree Direct; which is, PayPal's preferred integration solution for accepting direct credit card payments in your mobile app or website. Braintree, a PayPal service, is the easiest way to accept credit cards, PayPal, and many other payment methods.
How should I understand the direct credit card integration? Is that the credit card payment on the PayPal website after being redirected onto that page or do they mean credit card payments where the card number is provided on ones own website?
I've got the impression, PayPal is entirely shifting to Braintree Payments. Even on the official PayPal Developer website, they propose Express Checkout for quick (client side only) integrations and Braintree Direct for other payments.
This is what I need:
PHP integration of the API calls
Payment methods: PayPal balance, Different Credit Cards
eventually recurring payments
I do not need:
Third party invoicing
client management
shipping address management
So my concrete questions would be:
What's the difference between Braintree and PayPal payment methods (since they belong to the same organisation)?
Should I use PayPal Rest API or Braintree solutions in my case?
What are those PayPal limitations that they list on their website?
Has nobody got any experience in this domain? Even partial answers are welcome!
I have partial answer, as I am also in the process of choosing between BrainTree, PayPal Rest API, and Express checkout.
I'm here to answer "How should I understand the direct credit card integration?"
I'm no expert on the subject, but during my recent work at the area of integration with checkout systems, I've learned this:
One of the types of credit-cards is called "direct credit card". It means that it is directly connected with a bank account - when it is billed, the money is instantly transfered from the connected bank-account to the merchant. This is different than how most credit-cards work - most will only charge the bank-acoount at the beginninng of the next month.
I've come accross situations where direct cards behave differently than regular credit-cards.
For instance - the checkout-system I integrate with doesn't allow to monthly-bill a direct card. direct card on a monthly payment plan have to be billed manually.
So for me, the PayPal announcement you qouted means a lot - I need to support direct credit cards, hence I'm choosing BrainTree. Thanks!
Note to moderators:
I originally wanted to post this as a comment to the question, becuase I thought it would help the OP. I don't have enough reputation to comment, so I posted an Answer.

Taking payment from customer's card and giving to merchant

I am creating a booking site, where the public can make bookings and then pay using their card. I want to take the card details and send them to PayPal via their REST api, and then send the amount to a merchant who will be one of our customer's selling the booked product.
Is this possible to do? PayPal documentation is confusing at best. I currently have the card payments being taken successfully and paid into our own 'developer' account, but what I can't seem to find is how to credit the money to a PayPal account that isn't our own instead.
I have looked into the PayPal Permissions API but again the documentation is unclear, and I don't see where I specify the merchants id or email address when calling RequestPermissions.
What you're looking to do can be accomplished by using PayPal's Adaptive Payments product (https://developer.paypal.com/docs/classic/products/adaptive-payments/). Unfortunately, Adaptive Payments are not currently available with REST APIs. So if you have the option of going with classic APIs, this is currently available to you.

Paypal IPN set "no account" as default

I have a working paypal IPN, but ive been wondering: can I somehow set the "I have no paypal account" as the default choice when a customer is directed to paypal?
Short anwer: No, don't do that.
Long answer:
PayPal sets this dynamically based on customer information, primarily the cookie. In other words, people who have logged into PayPal on that device/browser before generally see that option presented first; people who have not are presented content that features the non-PayPal-login more prominently. This is done (primarily) to increase conversion for you (ie get the highest percentage of people to complete the payment & buy from you). Trying to defeat PayPal's code here would usually be counterproductive.
That said, there are also differences in how PayPal's screens are presented between various PayPal products (e.g. Payflow looks different from Express Checkout which looks different from Website Payments Standard) due in part to the mix of payment methods supported by each of these products, and also in part to expected customer mix with each of these. Some of these products also vary their behavior somewhat based on account settings or button/api parameters, again with the goal of being as effective for you as possible. But those parameters are product-specific and the question did not specify which PayPal product you are using.
As an example of variation between (and within) products:
Website Payments Standard (WPS) was designed to allow a merchant to accept payments from everyone, as the merchant's "sole solution." Express Checkout was originally designed to be used alongside a merchant's existing or separate credit card collection page, by merchant who would directly bill credit cards through a separate product (PayPal's DoDirectPayment or another processor). So PayPal's first WPS page was designed to present well to buyers with just credit cards or buyers with PayPal accounts. But a buyer would only be sent to the Express Checkout screen if they proactively chose to use PayPal rather than entering a credit card directly on the merchant's page, so PayPal's first Express Checkout screen could be aimed directly at PayPal account holders to generate the most intuitive buyer experience and highest conversion. Since that original version (ten years ago, in 2005!), however, Express Checkout has become more integrated into "PayPal Pro" and can also used as a sole solution, like WPS. For that usage it now supports an option that includes collecting card payments without a PayPal account.
PayPal also offers Payflow, Hosted Sole Solution, Adaptive Payments, and more payment flows.... each of which offers some slightly-different balances of buyer experience (and merchant experience/requirements -- e.g. some of these give the merchant access to credit card numbers and require PCI and merchant banking agreements, etc etc).

Feature supported list for PayPal Rest API for non US

Looking forward for PayPal's new RestAPI.
We have already started building and finding cool things as we go. Since its an on going process of releasing features it is still not clear sometimes what is supported and what is not. I am listing down my doubts for what is supported for Non-US developers.
Merchants cannot accept payments by taking credit card number.
Subscription / recurring payment possible?
For Pay with PayPal method, does Paypal offer to accept payments form non Paypal users? Like pay directly using card on Paypal page?
Do mention if I missed anything.
To register for a Live set of REST credentials you are required to provide:
U.S. Business owner Social Security Number, date of birth, and other personal details.
U.S. Business Tax ID (EIN, ITIN) and other business information.
Subscription / Recurring Payments are not yet available through the REST process. There are Reference Transactions allowed through "Vault" though.
There isn't an equivalent to "SOLUTIONTYPE" for the REST process yet but hopefully soon.