I'm struggling to pick the right Paypal solution for a small marketplace website.
The site has a number of vendors and customers buy directly from them. There is no commission or complication - payment is direct, buyer to vendor.
It crosses my mind that although I'm the merchant, I'm not the final funds recipient - so I can't see how I can make this work. I'd like to use Express, but I'm not sure that I can set the funds recipient to a third party account.
I don't want to use Adaptive. I've tried that before and it has some features missing (mostly relating to verified addresses, ability to list invoice items etc).
It also crosses my mind that if buyer A sends to Vendor B through the site, then there can be no IPN as the merchant is not the final recipient.
Really I'm looking for the right way to go to deploy a solid Paypal solution for this.
You could use Express Checkout for this. They vendors would just need to grant API permissions to your API username so that your user name has the permissions to execute Express Checkout API calls on their account. This will allow you directly process the transactions on their PayPal account. You can also pass over the IPN URL in the API call that you would like to have the IPN sent to. Also by passing it over in the API call, it will override the one set in the account for the particular transaction you pass it over for. This way the merchant/vendor can still use the one they may have set in their account for something else.
Related
I want to verify that whether user has entered valid Paypal id or not. If not than user can't do registration. I've also visited this [1]: How can I verify a PayPal ID? question but it doesn't help me :(
You can't find a direct answer because "valid PayPal ID" doesn't have a single fixed meaning. You will need to be more specific as to what you are trying to discover. Then there may or may not be a way to accomplish what you want, since PayPal protects some aspects of their customers' account and identity information for their protection (and for business reasons).
A bit of background that may help you clarify your question, if not necessarily answer it:
Any email (or phone number) can be configured to receive PayPal payments, in many cases even if the email was not attached to a PayPal account at the time the payment was sent. However, not all PayPal products can function in this way (e.g. you cannot make API calls as an account that has not been set up and has not generated API credentials). Are you asking about receiving money, and if so with which product(s)?
Most people can pay through PayPal if sent to a PayPal page, whether they are accountholders or not (depending upon the PayPal product being used). In addition to guest payments and/or direct credit card payments through PayPal, people can set up PayPal accounts when they arrive and immediately pay with them. So collecting email first and refusing to go forward if there is no PayPal account attached to that email would loose you potential customers. It would also "let through" many customers who could not pay, such as people who know an email address but don't own the attached PayPal account. PayPal also intentionally declines to easily answer questions about whether an email has an associated PayPal account in order to make it harder for bad actors to accumulate lists of PayPal accounts (often with associated personal information) for spear phishing campaigns. There are some APIs that allow you to get limited information about a PayPal account but there are limits associated with these APIs; see e.g. GetVerifiedStatus documentation at:
https://developer.paypal.com/docs/classic/api/adaptive-accounts/GetVerifiedStatus_API_Operation/
Note also that Verified has a particular technical meaning in PayPal, and is NOT AT ALL THE SAME as "able to pay you."
If you want to know if someone can log into their PayPal account, and then use that PayPal account to get information about the user (as well as potentially pay you), that's easy: use Login with PayPal. That's what it's for. Naturally this requires the user to login and assent to your use of their information.
If you want to know if someone can take a particular action (e.g. make a payment), at this moment, the only way to be certain is to actionally request that action. You have options short of actually requesting money; if you want to ensure the user has funds and reserve them for you to collect shortly you can request an authorization rather than a sale. If you want to make sure the user can log in, has payment mechanisms and generally looks ready to pay you (but WITHOUT reserving and guaranteeing funds) you can request an Order.
Hopefully one of these things is what you are asking for?
If you have a PayPal AccountID (a PayPal-generated ID rather than an externally-generated identifier like email or phone number) you can pass it to certain APIs (such as the GetVerifiedStatus), so many of the same options above apply.
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 building website which requires customer to update paypal account.
Is there anyway to check the reality of customer's account?
When my customer fill out their paypal account in my site, I want them to be directed to paypal login page to login and paypal will return the result.
Does paypal api support this situation?
Pretty much any implementation of PayPal you choose would follow the flow you mentioned.
Payments Standard would allow you to create basic buttons or create an HTML form and POST directly to PayPal to process. It would send the user to PayPal for login and approval to complete the payment. The transaction details would include the payer status (verified or unverified) as well as the address status (confirmed or unconfirmed) and lots of other details about the order.
Express Checkout is basically the API version of Standard, but it's much more advanced and open to integrate in the way that works best for your site or application. In this case, some of buyer/transaction data is available during the process within your app through API requests and responses, and then you can also get to it via transaction details after the fact just like payments standard provides.
Another option would be to use Adaptive Payments, but if you're doing a general payment of any kind you probably don't need that. That's what you would use if/when you start wanting to split payments among multiple receivers within the same transaction, setup preapproval profiles, etc.
If you happen to be working with PHP my class library for PayPal will make the API calls very simple for you.
You could do what PayPal itself does when you register. Send them a few cents and have them tell you how many when they get it. The payment itself will fail if the account doesn't exist, and telling you how many cents proves that they own the account.
I developed a Web Application that accepts payments via the ExpressCheckout API, for users to become a members.
Everything works fine.
I now want to extend my Web Application Services and offer my users with the possibility to buy items which are sold by third parties (my members).
The principle I would like to implement is quite simple: for each order, let the user pay for the item they choose and then transfer a part of the amount I received to the item provider, and keep some money for me. I would like to automate this process so that once I received the payment notification, I compute the amount of money to transfer to the item provider who might or not have a Paypal account (in other words, this means that I could maybe need to transfer the money to a bank account, using the IBAN/SWIFT data) and then proceed with the money transfer.
I tried to find a solution reading your documentation and came across the "chained payment" but the latter does not seem to be used within the ExpressCheckout workflow.
Also, since my implementation of the ExpressCheckout flow works, I would not like to have to find a totally different solution but rather extend it... if possible.
Could you please tell me which is the best solution for me?
In advance, many thanks for your help.
You could do 1 of 2 things. You could use Express Checkout with parallel payments. This means you could split the transaction up between different accounts at the time of purchase. The other option would be to just receive all of the funds into your account, and then when you are wanting to send money to the other accounts you could either use the Adaptive Payments (Pay) API or the MassPayments API to send money to the other accounts. Keep in mind you would have to send it to their PayPal accounts, you would not be able to send it directly to a bank account with either one of these API's.
I had the same issue and I got an answer from PayPal that it is not allowed to use Express Checkout to transfer money to your PayPal account and - at a later point in time - transfer the amount minus your service fee (which stays on your PayPal account) via Adapative Payments API to the seller's PayPal account. PayPal suggested to use Chained Payments API instead. All works fine in the sandbox, but once you need a Live APP ID from PayPal they will review your business case and deny it. At least that what happened to me.
I know that is old question, but anyway, I tried to find solution and was enable to perform the simillar thing like described in question. So, then I asked paypal about this, and they gave me advice to use SellerDetailsType Fields that 's called PayPalAccountID, description for this field is Unique identifier for the merchant. For parallel payments, this field is required and must contain the Payer Id or the email address of the merchant. It wasn't clear for me to use this field for solving my problem. Here is link https://developer.paypal.com/webapps/developer/docs/classic/api/merchant/SetExpressCheckout_API_Operation_SOAP/ I described field for soap request, for NVP it's called PAYMENTREQUEST_n_SELLERPAYPALACCOUNTID, but the idea is the same. I hope it will help someone.
Question:
How can I have a visitor to my site pay to a 3rd party PayPal account (one I do not have access to) and have PayPal return the visitor to my site, confirming that the payment was a success (while requiring no special setup or confidential information from the 3rd party account)?
Details:
My company provides a service to clients of other organizations, however, we collect payment directly from those organizations (and not from their clients). In our particular case, if the organization's client opts to use our service, they will pay the organization they are part of (and not us) - the entirety of their payment goes to the 3rd party organization (the value of the payment may vary, but it will always be billed as a single item). The only information we need from this transaction is: the ID of the client (a value from our database), and some type of verifiable confirmation (ideally, a dollar value paid).
The flow is as follows:
Our site
redirect to 3rd party PayPal
return to our site with confirmation
Authorize transaction and enable service
e.g. thank you page with Next button
payment needs to be authorized before going to next page
We would like to implement this in such a way that the 3rd party organization does not need to set up anything additional in their PayPal account, and does not need to share confidential information with us (ideally, they should only need to share their PayPal email address).
Currently, we are exploring using the following:
Buy Now button
Set the notify_url field on the form
Setup an IPN listener on our server that will process (and verify) the transaction
The problems are two fold:
We have been unable to confirm that this implementation would not require the 3rd party
organization to setup anything in their PayPal account (e.g. they
don't need to setup IPN, since we are using a per transaction URL
and they don't need to share their API key).
IPN is asynchronous - so we will not receive the notification as part of the transaction flow (which complicates things, but if no better option exists, we
can make it work). Is there any synchronous approach that would
notify us of a successful transaction without requiring additional
credentials (e.g. PDT requires an identity token so does not appear
to be an option for us).
If there are any better ways to approach this problem, suggestions would be appreciated.
You can use Parallel or Chained Payments to send money to multiple recipients, be able to control where the buyer is taken to after completing the payment, and you would get an API response back right away telling you if the payment completed or not. Using the Permission Services API calls you can set up your account as a third party to the receivers so they wouldn't have to make the changes themselves.
You mentioned that you're looking into using Buy Now buttons through Payments Standard. That would work for if you're looking for a quick and simple way of setting it up. Define the receiver as the business value and the money would be sent to them.
By default, IPN is set to "off" in an account which means an IPN post will still be sent out if you define it with the "notify_url" variable. You may need them to enable IPN within their account if they've previously disabled the service. If the receiver already has an IPN URL set in their account it would be overwritten by the "notify_url" value you provide.