Background
We are developing a webshop that we sell to other companies.
The companies hosts the webshops and sell their products on their own servers.
The webshop uses the Paypal Rest API for the customers to make payments.
https://developer.paypal.com/docs/api/
To activate Paypal as a payments method the companies provide their Paypal details in the webshop admin area.
How we do it now
Right now the companies need to create a Paypal Developer account, and then create a new App in developer.paypal.com to get their own Client ID and Client Secret Code.
They then provide their Client ID and Client Secret Code in the webshop admin area.
Question
Is this the correct way to do it?
We think it feels a bit strange to tell our customers (the companies) to create "Developer Accounts" in Paypal, when they are not actually developers, just webshop owners selling their products.
I found this information about setting a parameter called "payee", which means you can set the receiver of the payments, see: https://devblog.paypal.com/setting-payee/ and https://developer.paypal.com/docs/api/payments/#definition-payee
Is it possible to use the "payee" as a solution instead, like this?:
We as developers of the webshop have a Paypal developer account, and provide our Client ID and Client Secret Code, which are then used in all our customers webshops? Then the companies would only need to provide their Paypal Account Email in the webshop admin area, which is then used as the "payee" parameter.
Is this a good and ok solution? Or is the same App, Client ID and Client Secret Code not allowed to be used for multiple companies and their webshops? How can we solve this then?
Thanks!
This is solved after communication with PayPal support.
This is some information from the communication that answers my questions:
"Do not use then the payee field as you will be able to deal with all the transactions created, that you don't want as you are an external "actor" in the payment process."
"About creating a developer account and App it does not mean that they are developers. The developer portal is a tool that allow to manage the Apps and deal with Sandbox test accounts. It is the only way to create an App."
So the conclusion is that we are doing it the correct way today, which is like this:
"Right now the companies need to create a Paypal Developer account, and then create a new App in developer.paypal.com to get their own Client ID and Client Secret Code.
They then provide their Client ID and Client Secret Code in the webshop admin area."
Related
I want to make a payment system in which users can connect their PayPal account to a website. In this step, login required.
When transaction occurs, without having to log in again, users can pay to the site.
This would be quite different from PayPal subscriptions -- just auto payment like upwork client account.
What you are looking seems to be a "Reference Transactions" solution. It can be tested in sandbox, but to use it in live, the business account would need to be approved for this feature by PayPal. To do this the account owner would need to contact their PayPal account manager or PayPal's general customer support (not MTS), and explain the business need for this feature.
As far as implementing the solution, the only public documentation I'm aware of is for classic APIs: https://developer.paypal.com/docs/classic/express-checkout/ec-set-up-reference-transactions/ . Any newer API or vault solution does not appear to be publicly available at this time, but you could always contact PayPal's support and ask if there's something they'd rather you implement than those classic APIs. The more significant hurdle is the business approval for the feature mentioned earlier.
I am using PayPal Payments REST API to accept payments on some website.
Just now I noticed that both the transaction description as well as the app name (which you configure in developer dashboard) are no longer displayed. Why is this? Some recent change? Or something with my account?
It is very bad as I have a single company PayPal account which I use for various websites and the app name & transaction description is to give the corresponding payment flows their own identity. Currently people abort payments because they don't understand why the details in the payment overview on PayPal are completely different/unrelated from where they initiated payment.
Please see image below for what I mean.
If anyone can confirm this is happening for everyone now and/or refer to some PayPal documentation/statement regarding this topic then please share. I could not find anything on PayPal developer resources.
To display a 'custom' name, you need to create a custom 'Web experience profile'.
I was utilising the PHP SDK so did so by following their sample code.
You can also create a 'Web experience profile' with a direct request to the relevant API endpoint.
Once you have created the profile you simply set the identifier on the Payment object (PHP) like so:
$payment->setIntent("sale")
->setPayer($payer)
->setRedirectUrls($redirectUrls)
->setTransactions(array($transaction))
->setExperienceProfileId($this->config->paypal->experienceId);
I have a Java application that has just been updated with e-commerce features that use the Paypal REST API (https://developer.paypal.com/docs/api/).
I have multiple customers who run this application, each of them can log in to their own admin panel and manage their store and other features.
The Java client for Paypal REST API is working, I have tested it in the Sandbox of my own Paypal account and also in the live environment.
Question: Will each customer have to go into their Paypal account and activate the REST API to generate their key/secret for use in the Java app or is their a way for me to pay multiple PP acounts from the App/key/secret that is already active for my own PP account?
The only thing the Java app is doing with the PP API is creating and executing a payment.
If each customer has to create their own key/secret is there a quick way for them to do this from their PP admin panel? Currently the only way I know is to go into the developer.paypal.com section of the site, which doesn't seem very intuitive for a non techy.
At this time the PayPal REST API does not support third party payments in that way. The customer would need to use developer.paypal.com as you suggested to get their own PayPal REST credentials.
You can collect money and send it out using your own REST credentials but this would make you the liable receiver for the purchase.
PayPal has solutions outside of the REST API that might work for you here: https://developer.paypal.com/docs/marketplace-split-payments/
The Classic API does have a subject option, the subject is the third party. You do need permissions for some of the API calls; however, the permissions API can ease that process.
Currently we are using Paypal's REST API to setup a paypal payment process on our client's website.
Our webcontrol sits inside an iframe on their website and it is from this control the the paypal process is started and processed. Currently that works ok.
The issue we have is that this requires each customer of ours to have a business account (which is required any way we go so that bit is ok) but they then need to go the developer portal on their account and setup a an App ClientID and Secret (which is the bit we are hoping to do without to make it as simple as possible for our customers).
I have noticed solutions like wix.com offer paypal integration to their customers and only require the email address of their customer's paypal account and they handle the rest of the setup from there automatically.
I am just looking for some guidance on which product in Paypal's range should I be looking at to implement the same sort of solution setup for our customers?
Your observation is correct: the REST API service does not (currently) support placing API Calls for other users.
Alternatives:
Classic API: You can call the API in the name of a customer (who first needs to grant your API user access to his account) by passing the "SUBJECT=E-Mail Address" Variable. Usually used in conjunction with Express Checkout - see: https://developer.paypal.com/webapps/developer/docs/classic/express-checkout/ht_ec-singleItemPayment-curl-etc/
If you want to go this route, you may want to look into the permission service API under https://developer.paypal.com/docs/classic/products/permissions/ - it allows you to programmatically request the required permissions from a seller.
Adaptive Payments:
Often used by market places, we're dealing with 3 parties within Adaptive Payments:
a. API Caller --> The API caller placing the API calls and receiving all infos
b. The sender --> The person sending money to one or more recipients
c. The receiver(s) --> One or more receivers of the payment. As Adaptive Payments is pretty much using PayPals "Send Money" functionality, no further permissions need to be requested from the receivers.
See: https://developer.paypal.com/webapps/developer/docs/classic/adaptive-payments/integration-guide/APIntro/
Website Payments Standard: Just add a different e-mail address to the "business" variable and you're done.
See: https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/cart_upload/
I am working on a website in which a facility pays us for membership. Their membership payment is the only money we receive. This payment is done via Paypal Website Payments Pro using the DoDirectPayment API.
These members then rent out their facility to customers by listing available blocks of time on our website. The customer would pay for this time block via credit card, also via DoDirectPayment, but this time the payment goes directly to the member's Paypal account.
I have found a lack of clear direction on what needs to be done to enable this. I know I could require all members to have a Paypal Payments Pro account ($30 per month) and store their API credentials (including passwords and signatures) in our system and those payments could be handled directly. But I am vaguely aware of the Third-Party app authorization option... I just can't find info on how it should be set up.
Is it possible to only store the member's Paypal email address and just ask them to authorize our app in their profile?
Also, I saw someone suggest the thrid-party payment recipient wouldn't even need a Pro account. If that is the case, what do I need to change about the API call (I'm using the NVP method) so that our Pro account is leveraged but payment is given to the member?
First, your members will need their own Pro account. The only way to try and get around that would be to have all of the funds come into your account and then disperse them accordingly. This is frowned upon by PayPal and will result in a suspended account.
You could indeed have users enter their API credentials into your application and store them with your customer's profile so that you can include them in API calls for that particular member. You'll want to make sure to encrypt these values if you end up doing that.
The proper way to handle it (since you're a hosted solution) would be using Permissions. You would use your own API credentials, but then pass an additional parameter to flag what account you're making that call on behalf of. This is where the Permissions come into play. Your members will need to Grant API Permission for your app to make the DoDirectPayment call on their behalf.
This can be done manually from within the PayPal account under API Access, or programatically via the Permissions API.
OK, I discovered the answer. I am sharing the detail here for others looking for this very elusive information:
My account (hosted solution) must be a Pro account.
Members who will be selling to customers on my site must also have Pro accounts. I tested the same code with a regular business account and the error said "This transaction cannot be processed due to an invalid merchant configuration."
Members do not have to give me all their API credentials.
The DoDirectPayment call is the same as if I were doing my own payment (almost). I use my own username, password, and signature. The way to send the money to another account is to include one more parameter called SUBJECT which should be the email address associated with the member's Paypal account (not their API username).
The member must grant my (third-party app) account permission. In my case I only needed the one Paypal labels "Process your customers credit or debit card payments." which should correspond to DIRECT_PAYMENT in API terminology.
Andrew's answer gave me some additional keywords to use in searches, and I appreciate the tip off to the Permission API. It did not directly answer the question, but that will be a nice feature to add to my app instead of making users go through their Paypal profile's to grant permission.