Through REST API, I create Plans and I can create Agreements for subscriptions (recurring payments).
(As a general observations: PayPal should also allow plans to be created in the developer sandbox/live)
When creating an agreement, I use the Seller oAuth2 token (versus the Member's Token)
Webhooks set to 'All' in the developer account, testing OK, simulation OK.
However, when events (https://developer.paypal.com/docs/integration/direct/rest-webhooks-overview/#event-type-support) occur I don't receive notifications.
QUESTION:
Am I doing something wrong ?
Selecting "All" webhooks does not imply notification for all events related to PayPal. Selecting that will subscribe you to all current and all future events.
Right now none of the current event supports "Subscription Events". We would be rolling out support for them in future, and if you have selected "All events" as Webhook event type, your Webhook would be subscribed to them automatically.
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-
Paypal with active webhooks. We use a subscription plan.
When a customer
subscribes to the subscription plan PayPal's webhook sends us a BILLING.SUBSCRIPTION.CREATED.
We do not get a BILLING.SUBSCRIPTION.ACTIVATED. Can I expect it being activated when it is
created or do I need to double check that?
(Side note, when trying to send an api request to activate it, an error message informs me that the subscription plan is not “suspended”. So that looks like it is already activated. Logging into PayPal also confirms it is activated.)
The documentation on it is a little vague.
Created means the user clicked the button to subscribe. It does not mean they entered any payment details, or finished subscribing.
If you are not receiving a BILLING.SUBSCRIPTION.ACTIVATED event but the subscription is active, perhaps you did not subscribe to that event?
In any case, the most useful event to listen for is PAYMENT.SALE.COMPLETED. This will occur for the first payment as well as every future payment on the schedule. You can build all your business logic with only PAYMENT.SALE.COMPLETED , using every receipt of this event to mark how long the subscription is valid for in your system (e.g. 1 month from receipt)
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 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 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).