Is there a difference between being a Paypal Developer or being in the PayPal Partner Program? Should I sign up for the Partner Program?
I'm a web developer who has built an online store for a client of mine. I built a cart that passes all it's info to PayPal. I'm using the classic APIs. I just started investigating updating my code and I came across all this partner stuff. Should I bother with it?
If you're going to be building lots of apps on the PayPal platform I'd recommend signing up to be a partner.
It gives you access to marketing material, logos, error reports for your apps, etc. If you end up processing enough volume they may start giving you a small commission. You'll need volume in the multi-millions each year to get that, though.
Related
I'm developing a flutter app, and I've come across different payment solutions such as
squareup payments, paystack and stripe. However all these systems essentially require you to setup an account with their services, then you can only charge money to those accounts.
What I'm looking to do is enable monetary transfers between users on the app, and simply charge a fee on top. What are the best practises for such a system? So a callable api in the vein of Venmo, or Square Cash that I can call from code when I get the details I need.
Should I create my own backend for this? If so what should I use? (I'm primarily working in golang, but I'm flexible)
Or is there a nifty flutter plugin or API gateway that I can just use directly from the mobile client?
There are various services for doing such a thing,
Usually at my firm we would have our .NET rest server get the payment request from the client, and later charging it with some service that is verified for payments at our country.
Note:
You will be needing to associate with that service and there will probably be fees.
Depanding on your country, you most probably MUST NOT store the payment data on your own server unless you have a certificate for doing such a thing (security standerts etc.)
If this is a private project I would suggest researching about migrating with PayPal since you won't need to handle security and the payment would go through them.
May be helpful: paypal developers
We implemented the Mass Pay API to do mass payments from our app. When I went to create an NVP/SOAP API app to do this in our Prod environment, the form asked what APIs we planned on using. Sure enough, the Mass Pay API had (deprecated) next to it and told us we should be using the Payouts REST API.
As we were not live yet and still had time before go live, we bit the bullet and rewrote and retested the app to use the Payouts REST API. After creating the REST API app, I noticed Payouts was not 'ticked' for our Live environment, and has a "Contact us" button. So contacted PayPal to enable it, and after 2-3 months and half a dozen calls/emails and being told "it will be enabled in 24-72 hours", decided to contact merchant support.
Merchant support have now told us that the Payouts REST API is only available in the US (we are an Australian company and have an Aus PayPal account).
Yet their documentation clearly says Payouts is available in 150 countries? https://developer.paypal.com/docs/payouts/
I really don't know where to go from here - has anyone tried to do this? Any PayPal reps can shed some light on this?
So for whatever reason we decided to just try using the Payouts API in our live environment and it just worked. It's still unticked in the developer account, but it works in live.
Note: We did have to enable Mass Pay in the account.
I really don't understand, but glad we didn't have to re-write the app again!
I have a native mobile app in which I want users to subscribe for a monthly fee. I started by integrating with the native PayPal SDKs and use future payments, but in that case I'm in charge of processing the payments every month. I want a more automatic way where users approve their subscription and PayPal automatically posts the payments every month.
I have also started looking at Stripe, so if there is a solution using another library I would be glad to hear of that too.
(Disclaimer: I work for Stripe.)
Stripe does support recurring payments with the "subscriptions" feature. You can read more about it here:
https://stripe.com/docs/subscriptions
https://stripe.com/docs/guides/subscriptions
To implement this in a mobile app, you'd need to use the iOS SDK and/or the Android SDK. Both SDKs offer the same functionality: the ability to turn card information into a token, by exchanging the information directly between the user's device and Stripe's servers.
This way, the sensitive card information never hits your server, which greatly reduces the burden of PCI compliance. You can read more here: https://support.stripe.com/questions/do-i-need-to-be-pci-compliant-what-do-i-have-to-do. (This article talks about Stripe.js and Checkout, but the mobile SDKs serve the same purpose.)
Once a token has been created, you'd need to send it to an external server, where you would use it to create a customer object and a subscription, as explained in the subscriptions documentation I linked above.
The reason why this needs to be done on an external server and not in the app itself is because aside from the creation of card tokens, all other API requests need to be sent with your secret API key. You cannot embed or otherwise provide the secret API key to your app, as an attacker could extract it and use it for malicious purposes (they could refund past charges, use your account to test stolen card numbers, etc.).
I am working with PayPal integration for the first time and am confused regarding the two solutions. I need to accept direct payments. User enters credit card information and I use PayPal as the processor. I would also at a later point after release like to add PayPal Express Checkout for convenience. I have PayPal Payments Pro, which assigned me a Payflow account. Which documentation should I follow to accomplish both? There are so many assorted PDFs, many of which are over 100 pages, and I don't have a clear idea where I should start.
I would greatly appreciate a quick separation of services (XMLPay? DoDirectPayment?)
I am using C# / ASP.NET and already have the core and rest api libraries installed in my project via NuGet. I also have an app created and an ID+Secret pair to use.
I have called PayPal but the phone team does not have the proficiency to answer these questions and simply refers me to the documentation site. Hopefully a developer who has been down this road can steer me in the right direction. Thanks!
I would suggest the REST Apis, they support both direct credit card and express checkout depending on which funding instrument (CC vs PayPal) you pass in the pay request.
There is also a C# SDK provided to get you started, all info available at: https://developer.paypal.com/webapps/developer/docs/api/
For anyone running into this post in their search for more PayPal integration information (as I did), the C# REST API wrappers (provided by PayPal) are very useful, and they include full sample projects showing you how to perform most common tasks.
You can find them here: https://github.com/paypal/PayPal-NET-SDK
I have gone through the Paypal website, looked at their dozens of FAQS and documents, and still don't have a great idea as to how to integrate the Paypal Masspay API. I was hoping I'd have better luck on here :).
I have an app that gives users prizes, with an oracle SQL database that populates whenever a user redeems a prize.
Would I need to download the SDK onto my app, include the PayPal IPN, and call the MassPay API each time a user redeems a prize?
I have attempted to contact Paypal multiple times to no avail.
Not sure which aspect of your question is most problematic for you. I assume that you've looked at the concept diagram at
https://www.paypal.com/webapps/mpp/mass-payments
where the Excel worksheet is roughly analogous to a table's (or query's) worth of payees.
You would normally provide scripting code on your server/website that would submit that payee/amount list through the MassPay API calls against the PayPal website. If you only have one or two payees at a time, this is not the usual way to make a payment to your users (one-offs are generally Adaptive Payments API). It's not a downloadable app, though.
So is your app something the users download and interact with your site? If so, the correct place to put the code that faces PayPal (and actually transfers money around) is on your site's server. Not on the handset.
I finally reached a capable support member of the PayPal Team. The answer I got:
No SDK needed. All I need to do is set up an API call from my server to their server each time I want to reference a payment.