I own a personal PayPal account and am coming up with the design for a personal financing application. I intend to use the APIs provided by PayPal to fetch recent activity on my account to automate some of the information entry (at the moment, most of my transactions go through PayPal).
I've rooted through the API documentation, and I haven't been able to find any sort of endpoint I could use to fetch my recent account history.
I did find a question previously asked and answered about two years ago stating that the only way to do this was by getting a Premier account, which I'd rather avoid due to not knowing if there's any costs associated with such. I'd also like to note that despite my Personal status, I still get notifications on my Android phone stating that I've spent money.
Which brings me to the title question: does PayPal's API expose some endpoint I missed that allows me (the user) to programmatically browse my history, find new transactions, and mark them down with little input from me, or at the very least register to receive notice from PayPal that a new transaction has appeared?
You can pull transaction history using the TransactionSearch API. Then you can get individual transaction details using GetTransactionDetails.
You may also want to look into IPN, which will automatically POST transaction data to a URL you specify as a listener. That listener can receiver the data from PayPal and update your own database, send custom email notifications, hit 3rd party web services, etc.
Related
One of my customers had a website hosted on FusionHQ with subscription profiles through PayPal. When migrating the payments, I guessed I could just change the IPN and would get the new messages. But it seems that Fusion has manually set nofify_url parameters for their subscription profiles and there seems to be no way to change the notify_url.
Though slightly annoying, I guessed I could still use the classic payments API to get information and do something stupid like checking the subscribers' status on the assumed expiration date. But, it turned out that PayPal doesn't allow it because the specific API FusionHQ has used, with the following error message:
Subscription Profiles not supported by Recurring Payment APIs.
The thing is that there is no way I can get access to the old IPN server since it is on FusionHQ's domain. After searching through StackOverflow, I've really lost all hope of doing this in a decent way, and I'm about to redirect my customer's PayPal emails to some SMTP bot to parse them and give me the transactions update. But this is obviously a very crappy and unreliable way. So, does anyone have any idea of what to do?
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.
I have created and submitted a Paypal application ( using the classic API). The application is in a conditionally approved state. Paypal reached out and asked additional questions which I responded back with details. The application does not use the Paypal API to make payments. It only reads transactions related data and shows useful reports and insights for users. The API permissions requested are
1.Obtain transaction specific information.
2.Obtain your paypal account balance
3.Search your transaction specific information.
4.Search your transactions for items that match specific criteria and display the results
I was able to get a live app id and also have the API username, password and API signature. However since our app uses Paypal oauth, the permissions part doesn't work . My guess is this is because the app is conditionally approved. Is this the right assumption? Also what is the typical timeline for an app to get approved? My Paypal account from which I created and submitted the app is a verified account. I have sent messages from within my developer portal to support but I haven't heard anything back.
So far we have been working with a sandbox account. The live application I created is in a different account than the sandbox account. I am not sure if this is an issue.Would be great if someone who has been through the process can confirm.
Unfortunately there is not really a "typical" time frame for app approvals as too many factors go into the approval process. The best thing would be to call in to PayPal to inquire on the status.
I am working with the relatively new Paypal REST api and have successfully been able to create billing plans, approve billing plans, get a list of my billing plans, create billing-agreements (subscriptions), execute billing-agreements, and find specific billing-agreements.
I would like to be able to retrieve (GET) a list of billing-agreements, similar to how I can get a lit of billing-plans. This is not shown in the documentation as being available. Does anyone know of a way of doing this? Since there is no webHook available for subscription cancellations (or any subscription events) and no way to get a list of agreements, this leaves developers with no efficient way to handle cancellations (especially since users can cancel via Paypal without visiting the site). My current method/plan to handle this is to loop through all subscriptions that I have stored in my MongoDB (I store them when they are executed successfully), and send a request to Paypal for that specific agreement. I check its 'state' and update my MongoDB if they don't match.
There must be a better way.
I had the same problem, my first solution was almost identical to yours: I query the state of agreement upon user login and update the state in my db accordingly.
Later, I start to use IPN as my solution as suggested in this github comment by Tony: https://github.com/paypal/PayPal-Python-SDK/issues/69#issuecomment-69647946
The payments we gather on our website are for online subscriptions and registrations for conferences. In both cases, we want to gather absolutely all information other than the payment information ourselves, and ideally pass some of it on to PayPal (so users don't have to fill in name, address, etc. twice).
I know there are solutions where the information is gathered by the server itself and then redirected to PayPal via a web services call but that's not an option, unfortunately. All secure payment information gathered has to happen off-server due to network policy.
In addition, not every form will need to be processed using PayPal. Some people will be paying via check, etc. so they shouldn't be sent to a payment page at all. Most solutions I've looked at have a "Pay with Paypal" button, so I assume a form post is necessary to go to the PayPal site, but ideally we'd want to get there via a 302 redirect. Is that at all possible? (I'm aware we could do something like a form that was auto-submitted by JavaScript but I'd prefer to not go down that route).
Whichever system we implemented would need to handle recurring (periodic) payments also.
Paypal has something called Payflow Pro. They bought it from VeriSign a few years ago.
You can use it to do a full integration with the paypal api. So that the user enters their payment details on your site, and your backend code submits the transaction to paypal's servers. Paypal will then give you a transaction id back. Keep the transaction ID, chuck everything else (like the card number) out the window.
We have several clients that use Payflow Pro. It's very good and easy to use api.
I'm not entirely sure I understand the full scope of your question, but I think I do. I've coded a number these conf. registrations (though I have not interfaced with PayPal...rather iTransact and Plug'NPay) and in my applications, I had to read through the API documentation for the system being used (PayPal in this case). Then I logged into the payment gateway and usually they have an html form generator. All this does, of course, is returns an html form with the fields labeled appropriate to their API (so the billing name and address carry over from your system to PayPal's and the user doesn't have to re-enter their information), shows you what hidden fields you'll need(like cutomer_id, etc) and the form POST path.
Then what I do is I have the user register, preview their order details on another page (where you can choose to drop their info into a DB or wait until AFTER their credit card is processed) and then upon confirmation, they go to PayPal, pay with either credit card OR check (the options always exist) and when they hit confirm, the passback URL you put into a hidden var somewhere, takes you to a custom Thank You page (and hopefully processing script to capture successful transactions) which can be hosted anywhere on your servers.
It's pretty simple, just a bit labor intensive at first as you try and figure out the new form variables specific to a payment gateway API.
Hope this helped!