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/
Related
I need a solution that allows UserA to make a payment to UserB. UserA is a registered account in a web service that has their information stored in the "vault". UserB has no registered account and would simply pay at checkout by entering a valid card number. The web service would take 2% of the payment that goes to I guess a separate account for the website.
I am trying to wrap my head around which payment service to use as this is the first time I am creating a service with money transactions involved. I like Braintree specifically from what I see:
Free up to first 50k (good for a small cloud based web service)
Drop in UI that handles the encryption side of thigns for me (so it seems)
My question is my solution requirements need me to seemily split up the transaction that UserB pays from a card into two places - a portion to UserA and a portion to the web service. Does Brain tree offer a solution that makes this possible as I see it is with Paypal Adaptive Payments
Just looking for a quick link to the documentation.
I think Braintree supports "Split & pay". Refer : You can designate a service fee with each transaction and Braintree will disburse the appropriate funds to you and your sub-merchant..
And Paypal of course supports Adaptive payments. Refer : Adaptive Payments
I think all you need is in the above links.
I've made already some applications with the requirements of yours, and if I was you, I would consider Paypal Adaptive payments, because through the API, you can select how you want to "split" the payment between the receivers.
check this page for the configurations : page with configs
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 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.
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.
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.