Let's say I have a software that does accounting for businesses. These businesses collect money that, at the end of the month, they need to forward to their clients.
Meaning, at the end of the month, my software produces an accounting statement that goes like this
Send x € to Client A
Send y € to Client B
and so on
Today, the businesses then manually log into their bank account and type in every transaction.
But now, I'd like to automate that process by suggesting the businesses a "bulk transaction" on e.g. PayPal. At the end of the month, they log in and see a "Pay with Paypal" button. Once they click, they get taken to Paypal and the bulk transaction my software has created is shown to them. They can decline or accept it.
Once they've gone ahead and sent out the transaction, my software gets notified if the transaction was successful or not.
A few more things to consider:
My software is operated from Germany. Here, as soon as my software can "touch" the money of the businesses I'm serving, I'll have to get permission from BaFin. So I'd like to not have access to any money of the businesses I'm serving!
I want to make the process as smooth as possible from a UX perspective.
I've looked at the PayPal API. I've found that Mass Pay is deprecated. And so is Adaptive Payments... So the only option left would be the Payouts API. But I can't find a way where I can suggest the businesses a transaction but then get notified later if it was successful...
I could have them upload a csv. But then how do I know if it was paid?
Ideally, I could:
Generate a csv of all the recipients + amounts
Business downloads it from my software and uploads it to their Paypal. They confirm.
Somehow there's a webhook that calls my software to tell it whether the transaction succeeded.
I've also looked at the Reports API. In that case, I'd ask the businesses that I'm serving to allow me to access their reports and would periodically download them. But that neither seems to work as the Adaptive Payments API is deprecated.
Any ideas on how to solve this on PayPal? Any other providers I could take a look at?
Require all clients to be approved for PayPal Payouts and provide you with a ClientID and Secret to facilitate payments via the Payouts API. You can be notified via the Payouts API batch details.
If checking batch details isn't enough, you can implement webhooks for updates.
Related
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.
I am working with paypal first time.
I have a product and I want to integrate paypal with it.
I want to achieve the following tasks :
Client comes to my website and select a plan,which is a monthly recurring plan.
Then client is redirected to Paypal for payment.
Client makes payment.
Return backs to home page.
I have gone through the documentation of paypal and I have the following questions.
What should I use REST API or Classic Sdk, as I want to create Recurring Profile,Work with EXPRESS-CHECKOUT and REFERENCE TRANSACTIONS.
I have customers all over globe and it is stated in the documentation that, for the customers in Germany and China , I have to use REFERENCE TRANSACTION.
Some where in the documentation of Merchant SDK it is stated that the classic API's will be deprecated, so is it a good approach to use Classic SDK
I also wanted to track the transactions(payment) made by user, so that I can show him the amount that is deducted in each month in his profile details.
Please suggest a feasible solution to my problem.
Thanks in advance.
Here's what I use. I went to Web Payments Standard and created a Subscription button. (I like the unencrypted variety, but you can encrypt if you want.) In there, you set the terms of the subscription, as well as where to post the IPN message. When the IPN message comes back, you deal with it. You'll get a subscr_signup at the start along with a subscr_payment. Then, on renewals, you'll get a subscr_payment again. What I like to do is store every verified IPN message in the database for my customer.
For handling the management of those subscriptions for things like tracking info, refunds, subscription cancellations, and voids, you'll need to use NVP API, which is a very simple API. If you stored in a database every IPN message with all those fields, then you should be able to pass certain fields of those to the NVP API in order to get what you need done.
If you're worried about longevity of the APIs, then don't. All they do when they deprecate APIs is stop giving you good docs on them. They still let those older versions run. If they didn't, there would be major upheaval on the web with web commerce products breaking all over the place. However, that said, if you want to prepare for the future, then get on the Braintree Payments API because PayPal bought Braintree and that's the future of their API.
We use PayPal classic APIs.
We have a Linux server with some application/database running on it.
Users pay pages for ocr processing.
We need to offer to our users an option to make automatic payments when some condition is occured.
For example: when the user have left only 100 available pages.
In this case we want to offer to user something as "pay with PayPal 1000 pages everytime when my account have less than 100 pages".
Is this possible to do it with PayPal API?
Asolutely, this is simple to accomplish. If you prefer the Express Checkout API suite, the Reference Transactions product allows you to collect permission to re-bill your customers for additional goods and services when they check out. Then you call the reference transaction API when the event you are interested in (such as the user's inventory of prepaid pages gets low) occurs.
See:
https://developer.paypal.com/docs/classic/express-checkout/integration-guide/ECReferenceTxns/
Other PayPal products support similar behavior in combination with Adaptive Payments, the RESTful APIs, etc etc.
I'm new to PayPal and overwhelmed by all the possible approaches for integrating with PayPal.
As a start I want to implement one single subscription with monthly recurring payment. When the user returns to the site after fulfilling the payment, he/she will instantly be upgraded to "premium" member (digital product only - no shipping involved).
The first alternative I've looked into is the Express Checkout API, which looks ok, but is there any simpler way to do it?
Can I for example create a standard button (JS button or the form based), but still be able to verify the payment details when the user returns, using either the REST API, IPN or something else?
Any hints on best practices are appreciated.
Yes, there are entirely too many ways to solve this problem by now.
You can probably satisfy your requirements via buttons (aka Standard), Express Checkout (aka Pro) style APIs, or RESTful APIs, but there are a few gotchas to know:
First, PayPal has several products to do recurring payments; these products have functional differences and are tied to different integration styles. So (for example) PayPal's product called "subscriptions" (tied to Website Standard aka buttons) has different (and generally less flexible) capabilities than "recurring payments" (tied to Express Checkout) which in turn differs from "billing agreements" (tied to REST APIs, although the term "billing agreements" is also used in the express checkout recurring payments product). Oh, and there's another similar product tied to the Adaptive Payments suite of APIs.
Confused yet? Sorry. But it is important to determine whether the specific product you want to use will satisfy your requirements first before you do any integration, or you might end up redoing that integration work later (and potentially have to migrate customers, if you have already opened your business) in order to get access to specific features of another product later on. E.g., the subscriptions product has very limited ability for sellers to modify the subscriptions after they are set up. If that is OK, then great, use it -- it's simple to integrate. If I can oversimplify a bit: the Standard subscriptions product is the oldest and most limited; the Pro recurring payments is more flexible and mature; the REST billing agreement product is the newest, very flexible, but not yet as widely used; it may lack a feature you need today, but is the most likely to be continually improved going forward. I would not personally recommend the Adaptive product, although it also has its benefits.
Now, to your integration question: fortunately all these PayPal products can use IPNs. Unfortunately, IPNs are not instant. They generally arrive quickly (1-2 seconds) but delays can happen and it is quite awkward to be unable to process the customer. I would use IPNs only when shipping physical goods, not for immediate access to digital goods or in other cases where customers are waiting for a page from you. Fortunately, each of the other methods has a way to instantly determine the success of a PayPal action without waiting for an IPN:
Website Standard Payments will include GET or POST variables when it posts the user back to your site that will tell you about the outcome. If you use the Payment Data Transfer feature, these variables will include signature information so that you can post them back to PayPal & PayPal will verify their validity (so that a would-be thief could not fool you by engineering a post that looks like a PayPal success redirect).
The two API-based methods are even easier: the APIs themselves return all the information you need in the API response. So wherever in your code you make the call to create the subscription/agreement, if you get back a success then do your work to make your user premium.
There is the odd case of a user successfully paying and then getting "lost", as it were, e.g. the redirect failing/browser closing before they return to your site, or your site choking while trying to turn on the user. For this reason many people advise using IPNs, which PayPal will attempt to redeliver until you verify them back to PayPal. Not a bad idea, depending.
And of course you can call search & get details type APIs to get information about your transactions & agreements at PayPal -- although again, you will need to integrate with the right API that matches the product you are integrated with (e.g. Standard-based subscriptions won't show up if you ask the REST interface for billing agreements).
Hope this helps.
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.