I'm stuck at handling paypal notifications, and looking for some potential solutions.
I'm working on a upgraded/new site where users can subscribe and get access to premium materials - pretty standard stuff. Old site is currently running, and people have subscriptions there and the challenge is to keep those subscriptions running and have smooth transition to a new site.
Now i built new site on rest API and webhooks, and imported all subscriptions data from old site - this part is working, i can request subscription through rest api from paypal and i will get correct info, hovewer im not getting any notifications on my registered webhook from transactions that were made on old site (subsequent payments). When i subscribed on live with new site, notification about payment come through, same as on sandbox environment.
I figured out that the old site is using NVP/SOAP api, so my guessing is thats the reason why im not getting any notifications - am I right about it ?
Webhooks works in sandbox mode, and on live as long as the subscription was created through rest api.
I can make another NVP/SOAP app and setup it for my new site - then i can develop notification handler for that NVP/SOAP api but i don't know if this would receive those notifications then, or they are tied to that application that old site uses ?
I have webhook subscribed to all events and im logging any requests to it, so far the only one that came was from payment i made through new site - so i know it is working.
I would appreciate any help i can get on this subject.
The classic NVP/SOAP API does not have a concept of "applications"; its API calls are tied directly to the account.
So when you create an NVP/SOAP webhook listener, it should receive all events for the account.
Related
I am building the system to listen to the Payment changes in PayPal for that I research and recommended using Webhooks over the IPN.
As of now, I can able to create an app and add webhooks with event subscribers. Also, with the webhook simulator I am getting notified correctly but with the actual Payment made in the sandbox does not trigger anything to the listener.
I have verified the correct business account linked with credentials as well.
Everything is working perfectly except the Webhooks triggering from PayPal.
Also, as noting is triggering I do not have debug id as well.
If you have not registered any webhook listeners for any of your REST Apps (either sandbox or live), PayPal will not send any webhooks because it does not know which ones to send events for, or where to send them.
To register webhooks for an app, either:
Find the app for the correct sandbox account in My Apps and Credentials (or create one), and Add Webhook
Do so via using thewebhooks API, with the correct REST App client id and secret for authentication
Until you register a listener URL for event(s), no webhooks will be sent.
From a developer perspective, what is the best way to capture (webhook wise) a user cancelling their PayPal subscription via their dashboard (and/or subscription payment failing)?
I've had some discussions with PayPal support and have learnt the following:
Subscription button:
-simple, elegant, works well to let user subscribe
-however, when user cancels subscription via their dashboard does NOT fire a BILLING.SUBSCRIPTION.CANCELLED webhook. Only an IPN HTTP "webhook" gets fired. From the paypal docs, IPN seems harder to integrate (not REST, and for example the IPN simulator doesn't even have "subscription cancellation" events)
Using API (PayPal PHP SDK):
-DOES fire BILLING.SUBSCRIPTION.CANCELLED webhook events when user cancels their subscription via their PayPal dashboard (why this doesn't work for button-created subscriptions I do not understand)
-However, seems much more complex to set up than the button (what does the web flow look like?)
Just some thoughts on the best approach would be appreciated.
It depends on the type of 'Subscribe' button.
Legacy 'Subscribe' buttons created via e.g. https://www.paypal.com/buttons , will not fire a BILLING.SUBSCRIPTION.CANCELLED webhook. Those buttons predate webhooks by 10 years, and only use the very old IPN service. Stay away...
Current smart subscribe buttons, created via e.g. https://www.paypal.com/billing/plans or following the documentation do trigger the BILLING.SUBSCRIPTION.CANCELLED webhook.
In general, you can make use of the CANCELLED webhook and track this status if you want to but it's not necessary. The most important best practice is to make use of PAYMENT.SALE.COMPLETED and record when a subscription was last actually successfully paid for. If it doesn't get paid for again on time, then it's lapsed and you treat it accordingly.
When creating a subscription, along with the plan_id you can pass a custom_id which will be returned in all the webhooks. This can be useful for reconciliation purposes so you know which user it's for.
Using API (PayPal PHP SDK):
That SDK is deprecated, don't use it. Any API calls should be done directly via HTTPS.
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'm currently working on paypal sandbox enviroment. My web app based on nodejs is able to successfully create a new paypal sale and process the data. My problem take place when there is no webhook event related to the new sale even when it was all ok and it's logged into paypal-facilitator balance.
I already follow the paypal webhook integration guide and I am able to receive notifications with mock webhook simulator.
I haven't tested in live, but currently I have a webhook subscribed to the following events
Billing subscription cancelled
Billing subscription created
Billing subscription re-activated
Billing subscription suspended
Billing subscription updated
I'm receiving Webhook events for CREATED but nothing is being sent when a user cancels the subscription from their PayPal dashboard.
Is this expected behavior? is there another event I should be subscribe to to capture that user action?
Is there a debug id that you can share so we can trouble shoot?
Thanks,
Usha
From Paypal support (I still don't understand why the BILLING.SUBSCRIPTION.CANCELLED doesn't fire when a user cancels from their dashboard, similar issue here: BILLING.SUBSCRIPTION.CANCELLED does not fire upon user action?)
"But surely users subscribing via the button is the most common method of subscribing (how else would they subscribe?). The IPN route seems like a completely non-developer-friendly one (seeing as there isn't even simulator events for it)"
If you integrate a solution which is not based on our REST API's and want to receive HTTP notifications, you need to use instant payment notification (IPN). The IPN simulator may not provide a method of simulating the events, but you can create subscriptions in our sandbox environment and setup a sandbox business account with IPN and test cancelling the subscriptions, which will generate an IPN for the cancellation. We have a sandbox testing guide available here if you're not familiar with that environment and want to get started.
"So why would webhooks ONLY fire for API-based subscriptions (and why would a business website subscribe users using the API rather than the simple button)? What is the logic behind this?"
It depends on the integration and needs of the individual business. Some businesses only use our REST-based API solutions for their complete integration, from checkout payments to subscriptions and logically, this makes sense to them to only have to use one set of API's for their complete integration. Other business only want / need a more simple solution such as using buttons and as these are legacy solutions which are not REST-based, they use our legacy HTTP notification service which is instant payment notification (IPN).