Applying for PayPal adaptive payments, filling the form - paypal

So the idea is simple, the product is sort of a marketplace.
Main Flow
Sellers put stuff for sale
Buyers place order requests (application created preapproval on PP)
Seller approves order request (transaction happens and application receives the money)
Seller fulfils order request
Buyer approves (money released to seller, a % cut is taken by the app)
Buyer complains within 48 hours (refund or a dispute which can end in refund or no refund)
Pretty much technically we have it covered by PayPal's API, the problem is filling out the form on apps.paypal.com.
So, the questions I have are for the following sections of the form.
Services used by app
Adaptive Accounts
What are adaprive accounts? Is this for the app, sellers, or buyers?
3rd Party Permissions -
Request users grant you permission to make API calls on their behalf.
Are these permissions for the app? Or for some 3rd party apps, running under our app?
If it's for the main app, why's it called 3rd party?
Testing Information
How thorough and detailed does it need to be?
From the perspective of seller, buyer, or both?
How can I give them scenarios when we have different gateway now, and hence different workflow than what we want to achieve with PayPal? Or do I have to give them the staging site, after we've done the sandbox PayPal implementation?
Do they want staging or do they want to make purchases on production? Staging might be off here and there.
Any other advice
If you've been through the process yourself, please share your experiences, highs and lows.

Here are good instructions on filling out the paypal form and getting approved to use adaptive payments: http://www.chainedpayments.com/EZChain/SubmitAppToPayPal.html

Related

How to know when a transaction completes with Paypal?

I'm currently using Stripe Connect to allow sellers on my website to sell products to other users. I don't want to be a man in the middle and hold the money and then pass it along for legal reasons, so stripe connect works quite well for me, whilst still allowing me to know when a charge went through fully or was refunded, etc.
I'd like now to offer sellers in my marketplace the option to get paid by Paypal. This could be as simple as storing the seller's Paypal email and rendering the PayPal button on their shop, however, it seems now I wouldn't be able to track if a buyer actually finalized a purchase or abandoned the sale. I need this info for various reasons.
My question is how can I do this with PayPal?
All current PayPal checkout integrations have a "Capture" step, so you can know if a payment was successfully captured or not. Since you want to track this information on a server, you should use a server-side integration.
Implement two routes, one for 'Set Up Transaction' and one for 'Capture Transaction', documented here.
The best front end to use for approval is: https://developer.paypal.com/demo/checkout/#/pattern/server , paired with the above two routes you created.
Oh and since you'll be sending the payment to an account other than your own, specify this in a payee object when you set up the transaction.

Integration tests with PayPal

I would like to be able to test our integration with PayPal. We have sandbox accounts set up, etc, and I can even create payments. However, I'd like to be able to also issue refunds, query for refunds, and all the other APIs, all via integration tests and without human or even browser involvement. The difficult part seems to be that, of course, the PayPal flow requires someone to interact with a PayPal URL and approve the purchase.
Some more detail : We use the standard e-commerce flow on our site. User shows up, puts a product in a cart, proceeds to buy flow, selects a payment method, in this case PayPal. Of course, in PayPal's case, we create the Payment in PayPal and then simply show the embedded popup of palpal's flow where the user logs into their PayPal account and approves the purchase. PayPal does all this work. We simply get the response that 'yes, the purchase has been approved'.
So.. in an integration test environment, we can create the Payment entity in PayPal but.. how do we, in a sandbox environment integration test, get that payment approved? Is there a developer API available on the sandbox environment that says 'hey, this PayPal user approves this payment' or 'hey, this PayPal user rejects this payment', so that in test code we can simulate the buyer's flow. Or is there a way to set up a sandbox account to just 'auto approve' purchases or 'auto reject' purchases, simply for a test environment?
Yes, you can do anything in the sandbox that you can do on the live servers. This is a very broad question, though, so it's tough to answer.
For example, if you want to process payments without the need for any browser flow you'll need to have a billing agreement setup or a Pro transaction so you can run reference transactions. This would involve Express Checkout APIs and/or Payments Pro APIs, and reference transactions APIs. Depending on whether you're using Classic or REST, though, the API calls would be different.
In any case, once a transaction exists in the PayPal sandbox system you could then use the API to refund it. Same thing, though...you'd either be using REST APIs or Classic.
If you can provide more specifics in your question I can update this answer to be more specific as well.

How to accept subscription payments for services on my website that would go to multiple users

I am building an application that has two types of users: owners and buyers.
When a user signs up for a payment subscription to the services offered on the website, the system checks to which owner those selected services belong to and should then make that subscription payment go to that owner. So basically, users have no idea that payments go to multiple people. As far as they are concerned, they are just selecting certain services on our website and signing up for a monthly recurring subscription payment. The system then decides where that subscription money should go.
So, how can I do this? What possible systems can I use? I have looked into two: PayPal and Stripe. I can see how I might be able to use them for this if I get really creative, however I just wanted to ask you guys to see if any one has experience in doing something like this and what is a good way to do this.
Thank you.
Here're description about PayPal Adaptive Payment, you need setup preapproval and Chained Payment .
In this scenario, you act as Primary Receiver. You can setup the payment that Primary Receiver keep certain percentage amount ($10 in in 2nd picture), or distribute all payment to multiple receivers (service providers). It's up to your business logic.

Verifying paypal account

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.

Paypal Masspay API for amazon like site

I am developing a website where the users can sell their products. Users can then also buy products on the site, obviously, lol. However the problem is that I am currently using Paypals Parallel Payments and it limits the number of items a user can buy to 6 different sellers at a time including the sites fee.
So I was thinking about switching to using PayPals Masspay API instead. It would work like this. The user buys as many products as they want up to the limit of 250 different users using eithier the Masspay api if acceptable for 1-to-1 payments or something else. Once the payment is completed to the sites paypal account, It will start a masspay api call to pay all the differn't users upto 250 users using the funds from the payment to the site once those are completed.
Also I am limited to paypal right now so I can't use any other payment services.
So is this ok to do or is this a bad way to do it maybe for some security reason I do not know about?
It seems like the only good option, on the plus side, it benefits from the lower fees that masspay offers vs the %2.9 + 0.30 Cents.
First, you'd have to get it approved by PayPal to enable MassPay for your account.
Then, you'd need to be careful about chargebacks and dealing with refunds. If somebody submits an order for $1k, for example, and you dispersed that money among 25 different people, and then the buyer submits a dispute with their credit card company to get that $1k back, you'd be stuck trying to collect all those pieces from all the people you distributed to.