I would like to know how I can make an app where users can sell things and within this they can charge through the same app either by credit card or paypal, the part that interests me is the payments, that is, I would like to have several payments to different users how could I do this
You can set up a normal PayPal Checkout in a secure browser and specify a 'payee' recipient, documented here.
Related
In my Windows-Desktop App I want allow to transfer money from one Personal-Account to another Personal Account. What is the best way to do that?
Using Payouts seems to requiere a business account for the money sender.
In some countries, PayPal can facilitate fee-less "friends and family" payments from the PayPal balance or funding sources that don't charge significant fees, like bank accounts. If this is what you are looking for, all you can do is have the receiver of the payment create their own https://paypal.me link and direct the sender there, or if not using paypal.me then direct the sender to https://www.paypal.com/sendmoney to set up the transfer themselves.
Otherwise, only payments for "goods and services" are possible. There are many ways to set up a PayPal checkout between two accounts, and the receiver's account type is generally not of much importance although this may vary by country due to local legal regulations. A web page with a standard PayPal Checkout to pay another account can be set up with HTML/JS, so you could have your app show a browser with such a page. Alternatively, the much older (~20 years) integration method that uses a full-page redirect is to create a link with this template:
https://www.paypal.com/webscr?cmd=_xclick&item_name=purpose%20of%20payment%20goes%20here&amount=100¤cy_code=USD&business=emailusername#example.com
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).
I have an educational website that uses 'Stripe Connect' to accept payments from students, and split the payments between myself (the platform provider) and the teachers (content-creators).
Payments to teachers are currently handled through Stripe. Whenever a student purchases content, the teacher automatically receives the payment directly into their Stripe account. I retain a portion of the transaction directly into my Stripe account. It's an easy system and works nicely.
The problem is that students want to pay with PayPal.
So, I would like to add PayPal as a payment option for students, without forcing content-creators to connect two separate accounts--one for when viewers pay with PayPal, and another for when viewers pay with Stripe. The only idea I have so far, is to deposit all PayPal payments to one PayPal account, then manually "payout" teachers into their Stripe accounts every week.
But is there an automated way to do this? Stripe says they don't accept payments from PayPal.
Any ideas/help would be appreciated. Thanks!
Adaptive payments does support chained payments, as Andrew says in his answer; it would work very much like what you describe having set up with Stripe.
However, this will not meet your requirements of having both PayPal and Stripe payments arrive in a single teacher account. Unfortunately, Stripe & PayPal see each other as competitors and to my knowledge neither one has built a tidy product to consolidate "their" payments into the other company's account.
If you are willing to move away from Stripe, PayPal does provide many solutions that consolidate "raw" credit card payments and PayPal account payments into a single receiver account, including through Adaptive Payments as cited by Andrew.
I would add that Braintree, having been purchased by PayPal, provides perhaps the most Stripe-like integration for a product that would accomplish this goal. However, I do not believe that the Braintree SDK will do the chained payments for you; you might have to do some work to make that happen on your end (take the first payment, then calculate and make payouts either weekly as you mentioned or per-incoming-transaction).
A couple other things to think about: if you split some payments into delayed fulfillment but others are chained inside one payments provider you will need to support two very different flows; you may find it easier (for both you and your content providers) to select one model and run everything through that model.
Also, instead of payments going to you & then chained to the content providers you could have payments to go directly to the content providers and then trigger billing (either invoicing or automatically collected via recurring payments) from the content providers to you for your cut.
The best pattern depends largely upon how you want the legal & financial responsibilities to lie: are you providing the good or service and people are paying you for it, making you like a retail store or distributor for producers? Or are content providers providing the good or service being paid for to the students, and you are like a marketplace/facilitator/advertising venue? This question becomes significant as soon as someone is unsatisfied with something they have bought :).
You can use the Adaptive Payments platform with PayPal to split payments just like you're doing with Stripe. Specifically, you'd use the Pay API setup as a chained payment with a secondary receiver.
If you happen to be working with PHP my class library for PayPal will make all of the API calls very simple for you.
I am working on an app that enables customers to make on-the-go payments. I want the payment experience to be as effortless and hands-free as possible.
An example use case would be to fill up the gas on a gas station and not have to take out your wallet at all.
Ideally, I'd like to use services like Google Wallet, Paypal or Apple Pay etc. But I am not sure how to process and post the payment to the actual seller. In this case, what I can't figure out is how would I determine the actual seller and how I can link the seller account to my app, so the payment goes to the actual seller.
Any ideas on how to do this?
I'm going to offer my customers a selection of subscriptions to digital content. I want the customer to be able to add or delete subscriptions later, with as little hassle as possible.
It seems that if I use Paypal vault, I can collect the card information on the same subscriptions screen without multiple redirects and later change the monthly total without another checkout process or even customer sending approval to Paypal!
Does Paypal allow this? It seems too easy and also too permissive. Also, do I need to worry about PCI compliance?
Does anyone know a better way to do this (with or without Paypal)? I don't know how to use paypal recurring payments without a lengthy checkout if they ever change their subscriptions. Google wallet does not have subscription cancellation in their API! Several other alternatives only allow preset subscription amounts.
The CSC/CVV is missing from the examples here: https://developer.paypal.com/docs/integration/direct/store-a-credit-card/ which makes me think you cannot use the card at will. The customer is probably going to be asked for authorisation.
Normally your online payment provider needs to support recurring payments (installments, subscriptions). PayPal does, there's a specific API:
https://developer.paypal.com/docs/classic/paypal-payments-standard/integration-guide/installment_buttons/
For the customer it's one-off, then the card is billed, say, monthly.