How do I verify my receiver for paypal adaptive payments - paypal

I have what seems to be an uncommon situation. I need to accept payments on my website and send them to various merchants that do their business though my app.
So the payment flow is:
Payer -> My App -> My Customer
This flow seems to be exactly facilitated by paypal's adaptive payments api and while I have pored over all their integration guides, there doesn't seem to be any documentation for even simple email to account verification.
My question is, how can I verify that an email belongs to a verified paypal business account, or perform some other hand shake verification? Is there a way to do that, or even a good workaround? Thanks!

Found this API endpoint today:
https://developer.paypal.com/webapps/developer/docs/classic/api/adaptive-accounts/GetVerifiedStatus_API_Operation/
It seems to do what I wanted, and it at least indirectly test account existence and definitely tests the verified status.
One caveat that I would add for posterity is that in sandbox mode, you may only test against sandbox accounts that you have created for your app.

Related

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.

Braintree sandbox accepts non-existent PayPal accounts?

It seems to me that you can type in any random username/password combination and both the drop-in UI widget and the backend will accept it as a valid PayPal account. The payment will go through and everything.
Is there a way I can set Braintree sandbox to only accept real PayPal accounts?
Full disclosure: I work at Braintree. If you have any further questions, feel free to contact support.
The Braintree Sandbox allows you to pass any email address and password you like into the PayPal dialog, as mentioned in Braintree's documentation. You can test with the fake PayPal nonces found on the Testing and Go-Live page, but keep in mind, Braintree didn't actually design the PayPal sandbox for handling end-to-end tests. All PayPal transactions made in the sandbox use the same, fake PayPal account. Because of that, there's no way to configure your Sandbox account to accept real PayPal accounts. We recommend that when you go live, you perform a few low-value sale transactions with each of the payment methods you plan to accept, including PayPal.
You can test cases where the information in a PayPal account is bad in the same way you would test a bad credit card: use one of the fake invalid nonces from our Testing and Go-Live page. If your code is handling those cases correctly, you can be confident that it will be able to handle a PayPal account with bad information as well.

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 ExpressCheckout + chained Payment

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.

PayPal Chained payments error 520009

I am trying to setup a chained payment app, and got the application approved. I was hoping that like in parallel payments, chained payments can have users with or without a registered paypal account. But with email accounts that are not registered, the api returns an error code 520009 saying the account 'email#domain.com' is restricted. I did see the following link having the same issue.
https://stackoverflow.com/a/10262241/903978
Though in their dev doc says anyone with an email can get paid/ notified (except the app owner who needs a verified account), It is throwing an error. I have posted a ticket to paypal/mts but have nt heard from them yet.
My app case is,
1. User gets paid eg $100. They are the primary recipient in chain.
2. application (secondary reciever) gets a cut of this payment. say $2.
Any one know if chained payments need primary as well as rest of the recipients to have valid paypal accounts and not just an email? Or is there something in the call that allows primary recipients with just an email address?
( I know that application owner needs a registered paypal account).
Thanks
Paypal/mts confirms that their documentation is incorrect. Chained payments require confirmed paypal accounts and not just an email ID. They said they will update the documentation.
I can confirm this also, Paypal Adaptive Payments with Chained Delayed payments does require the secondary receiver and the primary one to be verified, but there seems to be some confusion about 'confirmed' and 'verified'. When pressing PayPal on this we discovered the criteria differs (or so they told us at Eco Market) and that users sometimes have to have confirmed their email address (simply clicking the verification email they get sent), but sometimes also have to go a step further and verify their account (going through the other steps like bank account confirm). They told us is varies based on country sometimes but for security reasons didn't tell us much more on how they do this (not overly helpful).
What we do to handle this is catch the error and as a marketplace we automatically contact the customer/seller to inform them the order cannot be processed due to the sellers account not being verified.
Going a step further, you could also validate sellers (again in a marketplace model) accounts by using the exact same API to take a small payment from them (which could be refunded using the API), which would allow you to validate sellers to make sure that they had a verified account before signing up.
Hope it helps if anyone else has any experiences of this and how they handle it I'd love to hear.
Jason Dainter
Eco Market
In my experience, in adaptive payments, (in particular chained payments) you need this environment:
a) the app holder/developer must have a registered and verified paypal business account (the premium account is ok too but not the personal)
b) the recipients must have a business account
if the amount doesn't exceed the limits it is ok if it is not verified too but if the amount exceeds the limit you'll have a problem in the chain.
c) the sender must have a paypal account, a simple personal account will fit.
Sometimes (rarely) happens that one payment fails due to restrictions on the sender email. The most frequent case I saw this happens was when the sender made a preapproval with one e-mail and then, before the preapproval was payed, he/she changed the e-mail in his/her paypal account. Silly but paypal has no control on this environment.
Hope this is helpful for you.
Cheers, Fil.
Genoa, Italy