My company uses PayPal Payments Standard. Currently our checkout process works via the "cart upload" method and IPN to verify payment via PayPal's website. Should continue to use this method or if we should replace this with the REST API? From what I understand, the REST API is only to be used when the customer stays on our website for checkout, as opposed to going to the PayPal site and returning to our site after checkout. If this is true, I assume the cart upload with IPN method is still the best choice for us, since at this time we prefer to have PayPal handle credit card data. Am I understanding this all correctly?
The REST API is just a different way to integrate the payments programatically. The functionality is very similar and you'll be just fine sticking with what you're doing. No logical reason to spend the time redeveloping it if what you have is working fine for you. They won't be killing it or anything like that (at least not any time in the foreseeable future.)
As i see from a brief view, REST API for Paypal offers webhooks instead of IPN as a way to notify your system about payments and their progress. Each webhook describes which url gets notification request when some type of event takes place.
Related
I've been developing a marketplace type platform. Implementing PayPal Payouts seemed to be perfect for dealing with commissions. Especially being as PayPal will be handling all payments too.
I've successfully developed this part of the system. Inc. the webhook and verifying transmissions.
Now I wish to get my eBay sales info into my system. So that we can see it all in one place and have the system work the commissions out for those sales too. Having just invested the time into learning and implementing this PayPal API integration, it would be nice to use it for getting this data too.
So having tested the sandbox app thoroughly for the Payouts, I configured the live one. This is in my PayPal developer account where the app settings are. I've done nothing in my main Paypal account. Am I meant too?
My live webhook URL is just set to log all received data from PayPal. So I waited for a eBay sale and went to check the log but no data received? Am I misunderstanding this? The webhook is subscribed to all events.
The Drupal Commerce shopping cart I'm using already implements a IPN. Is it the IPN that I need to be thinking about? I'd prefer to not interfere with it to be honest, to keep future security updates safer. That said, I suspect there will be a way to extend it.
I guess the actual question is - what is the easiest way to get eBay sales info through PayPal?
Any help would be much appreciated.
eBay has their own system for that called Platform Notifications.
If I'm working with payment data, and I just need extra data from eBay, I will typically start with PayPal IPN / Webhooks and then use the eBay APIs within my IPN app to pull and push data as necessary.
Of course, depending on the scenario, you may decide to build out your primary solution inside of an eBay Platform Notifications app, and then make calls to PayPal APIs within that if you need to pull/push data.
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 new to paypal integration in asp.net . I found very difficult to understand the paypal api .
I under stood two types -
inline html form ( i.e is also called buy button )
payflow api
my questions are :
which one must be used for recurring payment ( subcription packages for end user)?
in first type , few sites suggested to use IPN for confirmation of payment. I want to know is it neccessary since without using IPN, also using notify_url we can confirm the payment success (as per my knowledge notify_url returns to your site when payment is completed at paypal site)?
for recurring payment , do i need to store user account details (i.e credt card or paypal account ) in my databas?
please do reply with you suggestion .
Thanks
1) You can do it with both, actually. If you want to stick with basic HTML forms then you'd be using Payments Standard, and they call it "Subscriptions". You can easily create a Subscription button from within your PayPal account.
If you're using the API then they call it Recurring Payments (or Recurring Billing). You would use Express Checkout for the PayPal signups, and Payments Pro if you want to handle credit cards directly on your site without any redirect to PayPal.
IPN is useful regardless of what integration method you're using, however, don't get it confused with PDT. PDT sends data back to your site's thank you page, or whatever final page you setup for it, and it only works with Payments Standard. When PDT is configured on Payments Standard, even with Auto-Return enabled, there is no guarantee the user will make it back to your return URL. IPN is very similar, but data will always be POSTed to your IPN listener regardless of whether or not the user makes it back to your site.
You'll also want to use IPN to handle updates for future payments on a subscription / recurring profile. For example, the actual payments, cancelations, suspensions, reactivations, etc.
The notify_url parameter you mentioned is used for IPN. Again, though, this is separate from PDT. A common mistake I've seen many times is when people have their PDT and IPN both set to the same URL. Then when people do make it back to your thank you page, the code actually runs twice. Once from the user actually hitting it, and once again from PayPal's IPN server hitting it. So make sure to avoid that sort of thing.
3) No, you will never save credit card details to your server. The subscription / recurring system handles that using the data that PayPal saves on their servers.
I am building website which requires customer to update paypal account.
Is there anyway to check the reality of customer's account?
When my customer fill out their paypal account in my site, I want them to be directed to paypal login page to login and paypal will return the result.
Does paypal api support this situation?
Pretty much any implementation of PayPal you choose would follow the flow you mentioned.
Payments Standard would allow you to create basic buttons or create an HTML form and POST directly to PayPal to process. It would send the user to PayPal for login and approval to complete the payment. The transaction details would include the payer status (verified or unverified) as well as the address status (confirmed or unconfirmed) and lots of other details about the order.
Express Checkout is basically the API version of Standard, but it's much more advanced and open to integrate in the way that works best for your site or application. In this case, some of buyer/transaction data is available during the process within your app through API requests and responses, and then you can also get to it via transaction details after the fact just like payments standard provides.
Another option would be to use Adaptive Payments, but if you're doing a general payment of any kind you probably don't need that. That's what you would use if/when you start wanting to split payments among multiple receivers within the same transaction, setup preapproval profiles, etc.
If you happen to be working with PHP my class library for PayPal will make the API calls very simple for you.
You could do what PayPal itself does when you register. Send them a few cents and have them tell you how many when they get it. The payment itself will fail if the account doesn't exist, and telling you how many cents proves that they own the account.
My team is implementing PayPay Express Checkout (NVP) for our website. Before even initiating a transaction, we would like to perform a 'healthcheck' to confirm PayPal is alive and well. Looking over the API documentation, there is no obvious 'healthcheck' service available.
We are thinking of using the response from the SetExpressCheckout call to alert us of any system issues. Are we charged for every SetExpressCheckout call or for only completed transactions?
Making SetExpressCheckout calls and then abandoning the transaction, is this just going to anger PayPal?
Before we go too far into this, I'd like to mention PayPal APIs are in general quite stable, so such a thing shouldn't be needed at first place.
Having said that, are you seeing too many API failures? If so, I'd rather look into that (contact PayPal support) rather than using SetExpressCheckout as a way to do my own "health checks". Also, I suggest you to subscribe to such notifications at www.paypal-notify.com. This is PayPal website that allows merchants to subscribe for important notifications such as the one you are looking for.
Hope this helps.