We are working on an integration with PayPal's Transaction Search API. Official documentation here.
Regarding T0015 event code which as per the docs means - "Third Party Payout".
The question is:
Is this representing a payout for a merchant from PayPal account to a Bank account?
What does "Third Party" mean? Does it imply PayPal being a third party processor/gateway for a transaction between customer and merchant?
Or does it mean a payout made through a third party API? If so are there any examples to better understand this?
Thanks in advance.
The section is PayPal to PayPal transactions, has nothing to do with a banks. As a general matter, a payout from a third party is someone (a third party) sending you money from their account, as a payout action rather than as a purchase action.
If you need specifics about that event code you should contact PayPal.
Related
Im trying set up recurring payment on my site by using Paypal Express Checkout. I did read through the official docs and I couldnt find anything useful related to recurring payment.
https://developer.paypal.com/docs/integration/direct/express-checkout/integration-jsv4/add-paypal-button/
Im just wondering does Express Checkout support recurring payment? If so, how can I achieve that or Where can I get some good example to start with?
Thank you for your help in advance. Much appreciated
Cheers
We have a similar issue before. You might wanted to take a look at this thread.
I'm trying to understand the use case here. When you say recurring payment for express checkout,it has to be something a customer is buying regularly like restocking an item, in that case it's not an express checkout, it's a recurring purchase by a returning customer. They must have opted to restock at a regular interval like every 30 days, 2 months etc. They also must be registered users on your website.
So your logic must include — Checking all the customers who have set up an automatic purchase for an item.
—Check their frequency of purchase and charge them for the amount of the item at that frequency.
—For this purpose PayPal has a REST API :
This is the accurate place to look for to implement PayPal recurring payments:
https://developer.paypal.com/docs/api/payments/#payment_create
In case they also allow you to authorize payments through the following API
https://developer.paypal.com/docs/api/payments/#authorization
you could use it as well.
But at least this narrows down your choices in terms of regular payment authorization.
This API will allow you to request PayPal services to authorize payment on a regular basis for that customer. You will still have to have your own logic to check the 'subscription' for your products and the intervals.
—The CreateRecurringPaymentsProfile API Operation (NVP) at the link below looks to be for personal payments. For example something an Inventory Management System will do.
https://developer.paypal.com/docs/classic/api/merchant/CreateRecurringPaymentsProfile_API_Operation_NVP/
It's an API specific to adding recurring payments functionality.
Since you're a developer, PayPal Developers' Resources will answer any queries you have regarding the API functionality and usage. You will have to just know what to ask for. You are their B2B customer trying to understand their API system. You can also file a bug on their Developer portal if you're not getting proper answers.
I used the Paypal NVP API (Express checkout) for a long time and it worked fine. I'm now developing a new project and wanted to use the 'new' Rest API that Paypal recommends for new projects. I, however, find the documentation rather imprecise at some points and often contradictory.
I'm using their sandbox to test the payments and I noticed that the payments work fine, except that once I log in to the Paypal Buyer account, I can only select the PayPal balance to pay.
Is this a limitation of the Rest API? I want to clarify that I am based outside the US and I do not want to accept credit card payments on my own website (well, if there is no other solution, I would accept it). I'd rather have the user get redirected to the PayPal page and provide his credit card information over there. I do, however, want to give the option to the user to at least select from PayPal balance or credit card. (As I'm used to from the NVP API)
UPDATE
In the meantime, I've done a lot of additional research. On the PHP SDK page, they've added the following notice:
Important: The PayPal REST API no longer supports new direct credit card integrations. Please instead consider Braintree Direct; which is, PayPal's preferred integration solution for accepting direct credit card payments in your mobile app or website. Braintree, a PayPal service, is the easiest way to accept credit cards, PayPal, and many other payment methods.
How should I understand the direct credit card integration? Is that the credit card payment on the PayPal website after being redirected onto that page or do they mean credit card payments where the card number is provided on ones own website?
I've got the impression, PayPal is entirely shifting to Braintree Payments. Even on the official PayPal Developer website, they propose Express Checkout for quick (client side only) integrations and Braintree Direct for other payments.
This is what I need:
PHP integration of the API calls
Payment methods: PayPal balance, Different Credit Cards
eventually recurring payments
I do not need:
Third party invoicing
client management
shipping address management
So my concrete questions would be:
What's the difference between Braintree and PayPal payment methods (since they belong to the same organisation)?
Should I use PayPal Rest API or Braintree solutions in my case?
What are those PayPal limitations that they list on their website?
Has nobody got any experience in this domain? Even partial answers are welcome!
I have partial answer, as I am also in the process of choosing between BrainTree, PayPal Rest API, and Express checkout.
I'm here to answer "How should I understand the direct credit card integration?"
I'm no expert on the subject, but during my recent work at the area of integration with checkout systems, I've learned this:
One of the types of credit-cards is called "direct credit card". It means that it is directly connected with a bank account - when it is billed, the money is instantly transfered from the connected bank-account to the merchant. This is different than how most credit-cards work - most will only charge the bank-acoount at the beginninng of the next month.
I've come accross situations where direct cards behave differently than regular credit-cards.
For instance - the checkout-system I integrate with doesn't allow to monthly-bill a direct card. direct card on a monthly payment plan have to be billed manually.
So for me, the PayPal announcement you qouted means a lot - I need to support direct credit cards, hence I'm choosing BrainTree. Thanks!
Note to moderators:
I originally wanted to post this as a comment to the question, becuase I thought it would help the OP. I don't have enough reputation to comment, so I posted an Answer.
Using Paypal Classic API Billing agreement can be created. Agreement Id can be used for future payment using Paypal reference transaction.
Can this same functionality achieved using Paypal REST API? If yes please help me providing reference. I'm aware Billing Plan and Billing agreement can be created using Paypal REST API but without Billing Plan billing agreement can't be created.
Regards,
"Billing agreement" in RESTful APIs is specificly for Recurring Payments, and that might have misled you.
The terms are slightly different between Classic APIs and the RESTful APIs, and Reference Transactions is pretty equivalent to what is called "future payments" in RESTful APIs.
Technical specs are listed HERE, pls be noted that as of now, future payment has to work with mobile integration on top of PayPal MSDK (to obtain user consent and auth code)
Now this feature is available in REST APIs also. But please note this is a vetted product from PayPal. Not every merchant will be approved to use the Pre-Approved payments . Docs are available - But as a limited release
Docs for PayPal Reference transaction API. Also called as pre-approved payments
Looking forward for PayPal's new RestAPI.
We have already started building and finding cool things as we go. Since its an on going process of releasing features it is still not clear sometimes what is supported and what is not. I am listing down my doubts for what is supported for Non-US developers.
Merchants cannot accept payments by taking credit card number.
Subscription / recurring payment possible?
For Pay with PayPal method, does Paypal offer to accept payments form non Paypal users? Like pay directly using card on Paypal page?
Do mention if I missed anything.
To register for a Live set of REST credentials you are required to provide:
U.S. Business owner Social Security Number, date of birth, and other personal details.
U.S. Business Tax ID (EIN, ITIN) and other business information.
Subscription / Recurring Payments are not yet available through the REST process. There are Reference Transactions allowed through "Vault" though.
There isn't an equivalent to "SOLUTIONTYPE" for the REST process yet but hopefully soon.
My website allows user to buy stuffs, and the payments will be splitted between a few people (generally 1/4 people).
So far, the processus I use is to receive the payment into one account, and then use the Paypal Adaptive Payment API to send this received payment to all the people, based on their percentage.
The problem with this solution is that the "reception paypal account" will have a lot of input/output money and will be the Achille's talon of my e-commerce (if this account is suspended, my commerce is down).
My question is quite simple: is there a way to do this automatically?
I found that if the buyer have a Paypal account, then I could directly use the Paypal API to dispatch it's payment (based on his paypal email) to the people, and that is perfect, but the problem is : what happens if the buyer doesn't have a paypal account and want to pay with, say, a credit card?
Thanks for your help!
Ok, the solution is quite simple in fact but need a complete change :
I had to forget about Web checkout and use Paypal API, do a PAY request with a Chained Payment (defining multiple receivers, with one (me) setted at primary: true). In that request, set the ipnNotificationUrl to be notified of the evolution of payments and that's it!
The response from paypal, if correct, will contain a paykey.
Then, you have to redirect the buyer to :
https://www.paypal.com/webscr?cmd=_ap-payment&paykey={PAYKEY_HERE}
or
https://www.sandbox.paypal.com/webscr?cmd=_ap-payment&paykey={PAYKEY_HERE}
Then, to be kept updated, all you have to do is send a request to Paypal containing the paykey to know the paymentdetails !
That's it !
I'll answer my question on that, looking into the Paypal Adaptive Payment API, we can see a dedicated section "Guest Payments".
It seems it's possible, but it requires all the people that will receive the money to have a Business Account or Premium account!
Well I'll add a second answer because it's more complete and slightly different from the first one.
The best way to do it quite simply is to use the Express Checkout API (SetExpressCheckout, GetExpressCheckoutDetails, DoExpressCheckoutPayment).
By using it instead of the basic "checkout" bouton with an IPN behind, it is possible to define more than one recipient that will receive the money : the parallel payment.
It's that easy!
(Now I have to rewrite all my code to implement it, yayh!)