Why use Stripe webhooks instead of subscription.status? - stripe-payments

I am working on integrating stripe subscriptions in a website. So, I am thinking about using the subscription.status to monitor payment. So, once the current period ends, I check the subscription. If active, great, I update the user data. If not, then I act accordingly based on the status.
However, it seems to be that webhooks are the correct way to do this. Why is that better than just checking the status? It seems pretty much the same to me.

Using webhooks will allow you to keep a track of a whole bunch of things rather than just the status of a subscription [1].
You can design a webhook endpoint to listen to various events such as;
Whenever a new subscription is created or an existing subscription is
canceled
In case you offer multiple plans for subscription, you will
be notified if a customer switches from one plan to another
Whenever an invoice is created, finalized, paid or in-case payment attempt fails
If you don't use webhooks, you will have to constantly poll for status changes until the status actually does change. That approach isn’t really scalable. So instead of having to keep looking for the information, with a webhook the information would come to you.
So instead of having to keep looking for the information, information itself would come to you. You can use the webhook events as triggers to handle any operations you’d want to perform on your backend.
It will also increase the scalability of your app as there are plenty of other events you can listen for [2].
[1] https://stripe.com/docs/webhooks#use-cases
[2] https://stripe.com/docs/api/webhook_endpoints/create#create_webhook_endpoint-enabled_events

Related

Google IAP In App Purchase auto-renewing subscriptions Webhook for Subscription update / cancellation in NodeJS

Is there any way to implement a Webhook for automatic update of subscriptions on server side, in nodejs for example, for situations such as: the user renewed or canceled his subscription?
Currently I save the subscription data in my Database after purchase and use the Google Developers API to verify that it has been renewed or canceled when necessary.
However, for some Administrator routines I need to check all subscriptions at once and this includes calling the Google API for each one. This process is slow and can take a long time.
I could create a method that checks and updates all subscriptions according to the Google API response, and leave this process running through a Cronjob every day at night. I believe it will work, but a server-side Webhook would be the ideal solution.
Something which automatically notifies my server as soon as there is a change to a subscription so that I can update it in my DB immediately.
Found the answer. We can use Google Cloud Platform (GCP) to subscribe to topics and receive real-time notifications when a subscription change.
All steps are described in detail in their documentation: https://developer.android.com/google/play/billing/getting-ready#configure-rtdn

Stripe PaymentIntents + Subscription

Anyone know how to make a Stripe subscription charge a card automatically on future period payments using the new PaymentsIntent SCA approach?
Stripe's docs are in need of major pruning. I've never seen such convoluted and confusing docs as these ones.
One of the confusing parts is where they say in the docs for PaymentsIntents:
confirmation_method:
automatic
(Default) PaymentIntent can be confirmed using a publishable key. After next_actions are handled, no additional confirmation is required to complete the payment.
manual
All payment attempts must be made using a secret key. The PaymentIntent returns to the requires_confirmation state after handling next_actions, and requires your server to initiate each payment attempt with an explicit confirmation.
If I put automatic, the handleCardAction doesn't work anymore on the front end. If it has to be manual, does that mean that all future recurring payments (say Month 2, 3, etc) will need some kind of SCA confirmation by the user?
I haven't found any elements examples for paymentintents and subscriptions with SCA and varying plans and prices not pre-set on the backend as they depend on each individual's parameters.
If I use manual and handleCardAction, the subscription stays incomplete, despite the payment going through. If I use confirmCardPayment, the SCA popup never shows.
Looking further into the subscription and intent objects, I noticed that a new subscription created on the server comes with its own paymentIntent object. So does it mean one has to stop creating a separate paymentIntent with own id? If you do, it doesn't work for completing the subscription, which stays as incomplete.
However, the subscription's paymentIntent has a confirmation_method set as automatic by default -- this results in an error after SCA on the frontend: "You cannot confirm this PaymentIntent because it has already succeeded after being previously confirmed". Interesting, why did it ask for the SCA then in the status: "requires_action"?? Are we supposed to change manually the confirmation_method on a subscription to "manual"??
All this is quite confusing how to make subscription / paymentIntent work with SCA.
My logic is simple: user customises a subscription and enters card details, all of which gets sent to the server => Server creates a new plan, product, customer and subscription => Sends intent (from Subscription?) back to FE => If required, SCA is performed and the subscription is confirmed. Is this not how it's supposed to be done? I don't have pre-set plans as they can vary. I just need the ability to charge a user automatically the same amount they paid for the next period.
The examples and docs I've seen so far don't address the above use case. If anyone knows how to do it or can point to an example of how stripe elements and paymentIntents work with SCA and subscriptions that actually works and activates the subscription?
Stripe has a complete guide to fixed-price Subscriptions with Elements that sounds like it covers what you're trying to do.
When you're working with Stripe Billing (Subscriptions and Invoices) you rarely need to interact with the underlying Payment Intents; those are an implementation detail inside of each Invoice.

Authorize.Net Recurring Billing Events

I have successfully deployed Authorize.net API(currently sandbox mode) for subscription purposes. I have also configured its webhooks that are also working. But I have a confusion that still exists even after a week on working with the said API.
The question is, when a subscription starts in case of recurring billing(in my scenario subscription is monthly) the event that is called is
net.authorize.customer.subscription.created
When a month passes on a subscription and next bill payment is made by the API, what event will get called? How can I capture Or to what event should I be listening to? . Is it going to be
net.authorize.customer.subscription.updated
Currently I have clicked yes on all the all the events that are there for the webhooks
The event will be a payment related event, not a subscription related event. Subscription related events only happen when you do something to a subscription (i.e. create, modify, or delete) not with it (make payment).
So you would look out for any of the following:
net.authorize.payment.capture.created
net.authorize.payment.fraud.approved
net.authorize.payment.fraud.declined
net.authorize.payment.fraud.held

Set trial date on stripe dashboard only refer to plans not create them in my app using stripe

Not sure if the title makes sense, I will say this question is very similar to the one I posted yesterday but no response on seen here. I have a user sign up and select a plan, once they are set to said plan there is a trial day limit set using the stripe dashboard. I am not creating the subscriptions via the API. Once the day 30 days are up, how can I tell? Only way I can think of telling is checking if their account is older than 30 days and doesn't have a stripe token/last 4 numbers of their CC. There has to be a better way that is more secure and prevents them from canceling their card and still being able to use the service. I know there is no code in this post and should be, but the only code I think is relevant is in the linked post you should check out.
I should add, where should I put this code in my routes? And I am using node.js, express, swig, and stripe.
What you are looking for is Stripe Events. When an action happens on your account, Stripe issues an "event". You should set up a webhook in your dashboard, and an endpoint on your site or app to capture Stripe Events and process the data that is sent.
Stripe issues two perfect events for what you need: customer.subscription.trial_will_end which fires three days before the trial ends , and customer.subscription.updated which fires in multiple cases, including when the status is changed from trialing to active.
Read through the Stripe docs here to learn more.

Looking for some one who has implemented Moneris recurring payments for a website subcription

My client is using moneris as our payment gateway for a new subscription based website that I am working on.
I will be using the language PHP
I've looked through their documentation for PHP api and am comfortable with how it works, it seems very straight forward.
One thing was missing in the documentation for me though. There is mention of how to start a recurring payment, how to update a recurring payment, but no mention of how to query a recurring payment?
Some payment gateways allow you to have a POST back URL of sorts that get updates on recurring billing status. This does not seem to be possible with moneris.
How do I go about automatting the process of tracking recurring payments with Moneris? I'd like for my customers to log in and be able to view their transaction history on my site.
This information will also make it easier for me to know when to close accounts. Ie. when a payment fails to go through, or a credit card expires? I don't want for my cleint(owner of website) to have to keep track of the recurring payments and cancel accounts manually?
I got an answer from Moneris:
Hi David, We currently do not have a reporting API or any way of
posting the information from our recurring payments back to your
server. It is something that has been mentioned previously and is
being looked into. We do not have a current ETA on such a solution.

Resources