I have implemented subscription successfully, it is working fine. Now I want to know if a user has cancelled their subscription, I know that the cancellation is manage directly by apple, but what function to use from in_app_purchase to get this info. I have read that using _listenToPurchaseUpdated method you can get the data but, that is called during the subscription process, How can I get that data during users Login, in order to remove the subscription features in case the subscription was cancelled.
Thank you
Related
I have a SaaS with Paypal subscription.
In Paypal we can have a trial period as a part of the plan, which is managed by Paypal.
Is there any pattern to organize account deletion and subscription cancelation? I see some options?
Users can cancel subscription, but if they want to make a new subscription - they will get a new trial since it's a new subscription. I could get another plan without trial for this, but can't they substitute plan ID with the one with trial with some HTML knowledge?
Subscription cancelation can only be done together with account deletion. User can suspend subscription if he doesn't want to delete the account. Suspension is not exactly like cancelation, looks incomplete, like you may pay accidentally at some point.
Yes, a plan_id on the client side can be changed. You could conceivably create the subscription using the create subscription API call and fetch the ID of the created subscription instead, with a pattern similar to https://developer.paypal.com/demo/checkout/#/pattern/server
Subscriptions can always be cancelled in the payer's PayPal account.
Whatever solution you decide on, register for the webhook PAYMENT.SALE.COMPLETED and build you logic using that. For reconciliation, add a custom_id when the subscription is created; this can essentially be your own user ID or whatever other unique identifier you want.
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)
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'm working on a Paypal subscription based website.
I can not find an API method to get my subscribed clients and their subscription's status.
I only found a file to download manually, and it is not practical to check that way.
Basically what I want is to disable users when they cancel their subscriptions.
One way to go would be to use IPN to notify you when the subscription is cancelled and use the notification to trigger the the action. You can have a look at the documentation here.
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).