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.
Related
I have a subscription based web site where I would like to get statistics about all the current active subscribers and how many cycles they have made. This would have been easy task if the PayPal API had an endpoint for fetching all subscriptions but this is missing from their API. So I'm tracking this in our DB. I'm successfully recording the new subscriptions and the cancellations. But I'm not sure what event I should expect from PayPal to be triggered when a subscription renews.
In PayPal's documentation I have found only few events related to the subscriptions, and none of those seems to serve my needs. There are also an event called BILLING.SUBSCRIPTION.RE-ACTIVATED but it comes from "Billing plans and agreements" which is deprecated.
In SO I have found this post which advises to check for the PAYMENT.SALE.COMPLETED, but this is not perfect as I will get all sort of payments that hit this PayPal account (it is used not only for subscriptions but also for one-time payments).
It's PAYMENT.SALE.COMPLETED
For one time payments, a /v2/checkout/orders integration shouldn't trigger that same event, only the deprecated /v1/payments does AFAIK.
You can tell whether it's a subscription payment by the payload, subscription IDs begin with I-
I am currently integrating Paypal subscriptions into my ReactJS WebApp.
A user shall be able to subscribe (and pay a small fee) to use premium features.
I wonder how to handle cancellations. What I would expect is when a user subscribes for a one-year period and then immediately cancels, he/she shall still be able to use the service for the paid period (one year).
With my current solution, however, upon cancelling, the access to premium features vanish immediately and does not let the user to access the service he paid for(and cancelled later).
My current solution looks like this:
Subscribing already works by using this paypal button: https://www.npmjs.com/package/react-paypal-button-v2#subscription-example-usage
Cancelling also works using this API call: https://developer.paypal.com/docs/subscriptions/full-integration/subscription-management/#cancel-subscription
This also triggers a webhook of my app with the event BILLING.SUBSCRIPTION.CANCELLED. Then immediately the account is cancelled and the user cannot use the features he already paid for.
How do the events BILLING.SUBSCRIPTION.CANCELLED, BILLING.SUBSCRIPTION.EXPIRED, BILLING.SUBSCRIPTION.SUSPENDED, BILLING.SUBSCRIPTION.ACTIVATED relate to each other ? I did not find any documentation about his.
Is there an event or a workflow that I can use to accomplish what I intend ? I currently develop this using the sandbox features.
Or do I have to implement the necessary logic by myself?
PayPal only keeps track of whether the subscription is active.
Cancelled or Expired are how it became inactive.
On cancellation, you need to implement any "already paid for" logic yourself, PayPal does not do this.
I am trying to set up a recurring payment with PayPal Subscription REST API. I'm following the Basic Integration in PayPal Developer Portal, using as suggested the Smart Payment Button. Besides, I'm using a WebHook to "capture" events related to subscription.
As the tutoria suggest, I created a Product and a Plan.
Now, I rendered the Smart Payment Button in a page (using the example), and when clicked it triggers the PayPal authorization flow. When the user complete the subscription process, the BILLING.SUBSCRIPTION.CREATED event is triggered. Later, also the PAYMENT.SALE.COMPLETED and BILLING.SUBSCRIPTION.ACTIVATED are triggered, and I receive data in my WebHook. Now, I have troubles in identifying which user activated the subscription. My idea is to pass a custom variable (with something allows me to identify the user) and retrive it later when the WebHook post me data, but I can't undertand how to do it. Anyway, is this the best way to do it? Or there is another solution?
I solved this using "custom_id" in the smart button:
return actions.subscription.create({
'plan_id': 'PLAN_ID',
'custom_id': 'CUSTOM_ID'
});
Then, I receive custom_id from webhooks or querying the subscription.
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).
I have REST API created Payment Plans and agreements and would like to be able to detect when a user cancel an agreement. My original take on this was that the cancel_url on the merchant_preferences object for billing_plan would be used if a users canceled the agreement through the PayPal API, but I am not seeing any callbacks coming in so perhaps this is incorrect?
I have seen plenty on information on IPN processing cancellations and I would love to know if that is the only way to receive a cancellation notification or should I be using another field in the REST API to set this up?
I'm not against using IPN (hey whatever gets the job done!), but it seems to me that the REST API should have its own capabilities for achieving this as well.
Hey this is Avi from PayPal. Refer to this github issue for information about getting IPN notifications for subscription events.
The REST API does have webhooks, and work is in progress to support subscription events for webhooks as well.