I have looked at the Paypal REST API and at classic API. I like the Direct card processing support the REST API offers and the ability to use the Vault from the REST API.
Only problem is our PayPal sales rep insists the REST APIs are not stable and should not be used and wants us to use PayPal payments Pro with this Class API .
We have a business account and only expect to receive payments in the US, which per this link should be supported just fine. We need to accept payments using a mobile app and website. The mobile app needs to support one time transactions and both (app and website) need to support transactions using stored credit card information (which is where the Vault feature seems really handy).
I clearly see a lot of REST API questions so now doubt its in use.
Question for devs using the REST API over the past 6 months:
has it changed in a breaking manner for you?
Is it reasonably available (99.9%) for your applications?
Does using the Vault REST API feature require a Payments Pro account?
The RESTful APIs would work for you based off of what you stated. Granted they are not to parity with the Classic APIs just yet but the features you were requesting (Direct Card and Vault) are good to go. Pro is not required for Vault with a US account.
Lastly, without knowing the full conversation you had with your Sales Rep, I can't comment on why they felt so strongly against the RESTful APIs. However, if you open up a ticket at www.paypal.com/mts with all of your integration requirements, we can help you out with the best options available.
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
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 for a company that is using Paypal pro. There are so many Paypal account types, API's, and SDK's that I am starting to get confused with it all. At developer.paypal.com, there is documentation for many different things. What API and/or documentation do I use to start integrating paypal into my website? What is the difference between all these different ones?
Any advice or help would be great, as I am stuck.
Thanks for your time!
Personally, I would avoid the REST API and stick with the Classic API for now. The REST API is very new and doesn't do (much) more than the Classic APIs do. In fact, the Classic API is much more mature has a lot more functionality, which is one of the reasons I still prefer and recommend it.
With PayPal Pro you will use one of two APIs depending on which version you have.
Website Payments Pro 3.0 - This uses the DoDirectPayment API
Payments Pro 2.0 - This uses the PayFlow API.
Payments Pro 2.0 is actually the newer version. If you're interested in more detail on that you can take a look at my article on the History of PayPal Payments Pro.
So those would be for direct credit card processing through your site / application from your own custom checkout page. To add PayPal payments to that, you would use Express Checkout APIs. Specifically,
SetExpressCheckout
GetExpressCheckoutDetails
DoExpressCheckoutPayment
If you are working with PHP this PayPal PHP SDK will make all of these calls very simple for you.
I am looking into implementing Paypal Standard Payment product. The basic reason being "offsite payment" (i.e. we dont want payments being captured at our own site, but on paypal's own payment page via redirection).
However, previously I used to get it done via (now called) Classic API.. I wounder if the new REST API supports this offsite / paypal redirect standard payment method? This is because there is no mention of these classic products names on the REST documents (instead, they are listed in Classic API section only)
Secondly, does Paypal Standard (even via REST) support Direct Card payments? or only Paypal Account payment?
Thanks.
REST does not encompass all Classic API features. It's mainly for mobile development (although not exclusive to that), using OAuth, which is more familiar to mobile developers. Payments Standard is not an API product at all but it can be used in conjunction with API calls to a limited extent. Classic API has the Button Manager that lets you set up custom encrypted buttons that can start a Payments Standard payment.
REST does support direct payments and supports almost everything Classic does in that regard.
I used the PayPal sandbox last year when integrating a website with PayPal Pro and it was pretty straightforward. The new and improved version is confusing the heck out of me, though. Nowhere can I find an actual definition for what an "app" is (I'm not kidding, I can't find a definition anywhere) and I'm confused on what I need to do to access the sandbox.
Do I need to create an "app," or just create sandbox accounts?
It depends on which APIs you're using. Adaptive Payments and related APIs (Adaptive Accounts, Invoicing) require a "classic" APP ID. And REST APIs require a newer app to get credentials.
Classic APIs such as Express Checkout and Payments Pro do not require any app; merely an appropriate Business sandbox account.
So, start by figuring out which API you want to use, and then follow its documentation.