We are currently using Stripe to offer a subscription service with 30 days free trial. Since we don't want the customer to be able to start the free trial without authorizing one payment method we use the SetupIntent of the created Subscription to present a card input to our client. Now the issue is that even before the customer is shown the card input the subscription is already created and "paid" for because it is a free trial.
This means that we cannot listen to the initial invoice.paid Webhook to activate the account, but instead need to listen to setup_intent.succeeded. This seems a bit odd and requires us to link the SetupIntent to a Subscription. It also means that when a customer cancels the subscription process before entering their card details, that Stripe still has created an active Subscription in trial.
Is there something we can do differently, or should we just accept that the subscriptions where the SetupIntent was aborted will be inactive on the Stripe side once it tries to pay for the next (non-trial) invoices?
Stripe's docs use the Setup Intent that's created with a trialing Subscription to collect a customer's Payment Method, but for your use case it may make more sense to create your own Setup Intent up front and not create the Subscription unless the Setup Intent it successful. It'd go something like this:
Create the Setup Intent
Confirm the Setup Intent after collecting details
If successful, create the trialing Subscription
Alternatively, you could try using Checkout which does require users to submit a Payment Method even from trialing Subscriptions
Related
for my subscription based product I want to have a possibility to subscribe and enter payment details at once with stripe and struggle with that with the api.
In https://stripe.com/docs/billing/subscriptions/build-subscriptions?ui=elements I see an option to create a subscription with payment_behavior='default incomplete' and then enter the details to confirm the payment intent. So far so good. However if I create the subscription like that even before the customer confirms payment details stripe already generates an invoice which is not really what I want before final confirmation by customer.
Options I see:
create setupintent, have this filled by customer via elements and then have the customer subscribe. Technically works nicely but for a sales and customer perspective is not good as it has two steps thus probably reduces conversion.
create the subscription in the background before final subscription confirmation by customer and use the clientsecret of it to pass back to browser and then have customer enter his payment data and submit that and finish the setup of subscription and payment info. Technically works - however I realize that when I create the subscription to get the clientsecret to pass to elements before the customer enters his payment data and confirms the subscription the subscription is not only created but an invoice too - which would be really, i.e. an invoice created before customers really confirms the contract
create setupintent and submit it via elements and in metadata of it add the info of product that customers wants so that when the paymentmethod gets created and I get webhook event I do the booking of the product given in metainfo. May however mean the customer gets to success page but the webhook has not notified yet and thus the customer is not really subscrubed at the point in time but gets a success message he is
same as 3 except do not pass info via metadata but via successUrl parameters which refers to and endpoint at my backend which upon being called after setupintent was setup will do the subscription and then redirect to my frontend which shows success page. That seems like a error prone workaround however.
Create a workflow which is a 2 step sign up and asks for paymentinfo, sets that up and then brings customer to a final confirmation page where the submit triggers subscription creation. Seems a bit complicated from a user flow, but so far probably the best option?
Any better options?
Cheers
Tom
ps: Interestingly enough on discord stripe support told me #2 is the way to go - find it hard to believe ...
As far as I know, there isn't a workaround for this unfortunately. It is just how Subscriptions API is designed by Stripe. You can learn more about that here where they talk about "how subscriptions work".
Background:
When creating subscriptions through the Stripe API, you can use payment_behavior: error_if_incomplete when you want Stripe to return an HTTP 402 status code in case a subscription’s first invoice cannot be paid. In this case Stripe does not create a subscription at all if the payment fails.
Question:
Is there a way to achieve the same behavior when using Stripe Checkout?
My experience is that even if the payment fails, Stripe creates a subscription with status: incomplete which is then expired if no successful payment is made within 23 hours. I've checked the parameters for creating Checkout Sessions but found no option to set payment_behavior there.
Sources:
https://stripe.com/docs/api/subscriptions/create#create_subscription-payment_behavior
https://stripe.com/docs/api/checkout/sessions/create
Bad News
Unfortunately this is not something that can be configured presently. When Checkout creates a subscription, all the parameters not provided directly are set to the Subscription default. The default payment_behavior for a Subscription is default_incomplete.
Good News
You can achieve this behavior using Webhooks. You would listen for the invoice.payment_failed event, check the billing_reason property of the invoice is subscription_create (identifies the first invoice of a new subscription), and then cancel the related subscription.
If you are using Subscriptions and Invoices, it is recommended you use webhooks anyway to keep track of changes in status.
We are working on a service that can start a subscription later in the future: users say today they want the service, but it actually starts some days later.
We are now collecting the payment method through a SetupIntent, which allows the user to verify they own card, but it actually doesn't verify the credit availability. When we collected the payment method, we create a scheduled subscription with the verified payment method; then, when the subscription starts, Stripe uses that payment method to collect money.
It happens, sometimes, that users do not have enough credit to pay for the service when the subscription starts. Otherwise, it also happens that, when Stripe tries to get money, the customer's bank requires 3D-secure verification.
Since our subscriptions start at midnight, we would like to avoid having to involve users again in the payment process.
So, we thought: would it be possible to immediately collect the payment method through an hold on a PaymentIntent and confirm that hold only when the subscription starts? I can't find a way to do this with Stripe (don't know if it exists). It seems impossible, with Stripe, to generate a PaymentIntent (with capture_method set to manual) for a scheduled subscription.
Do you have some ideas on how we can avoid payment problems when the subscription starts?
Otherwise, it also happens that, when Stripe tries to get money, the
customer's bank requires 3D-secure verification.
This shouldn't be the case if you complete any required 3DS authentication as a part of the SetupIntent confirmation flow. Call confirmCardSetup whilst the user is present and that way the payment method is successfully verified and can be used to process off-session payments for your subscription as you need.
You can use Stripe to place a hold on a card, but this generally doesn't apply to the use case you've described.
I found a workaround for this by first creating a paymentIntent with setup_future_usage="off_session" and capture_method="manual" to first place a hold and save the paymentMethod, and then, only after capturing this paymentIntent, creating a subscription using the newly saved paymentMethod with billing_cycle_anchor that equals your subscription's interval from now.
This way it's like your customer has paid for the first interval using the paymentIntent, but will be charged from the second interval using the subscriptions API, which allows you to cancel the hold on the first payment and not create a subscription if something goes wrong.
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.
I have a subscription, I collect card details on signup with a 7 day trial, after which the subscription bills monthly.
From what I understand the subscription API is not SCA compliant. Instead
An off_session payment Intent must first be setup when collecting card details.
At the end of each month a scheduler must be triggered to attempt to charge the registered card.
Is this the case? Am I now responsible for scheduling payments?
Update
For those who want some starter code, I created a working playground here with subscriptions, frontend (react) and backend (express) on glitch.
It's not true that Stripe's Subscription API is not SCA-ready, it is, and you don't have to set up your own scheduling like that. The docs you linked to are generally aimed at processing one-off payments(like saving a customer's details and then allowing them to use them again when they re-visit your site to purchase something new, for example) as opposed to recurring ones.
https://stripe.com/docs/billing/subscriptions/payment describes how to set up a subscription in a way that is SCA-ready. While the customer is on-session on your payment page, you collect card details and create a subscription for the customer, which will generally attempt a payment for the first billing period. You then check the status of the subscription after it's created, and handle the outcomes:
the subscription is active and the payment was successful, so you can proceed with provisioning your service to the customer.
the subscription is incomplete — for SCA purposes, let's say this is because 3D Secure authentication was required for that first payment. In this case, the latest_invoice of the subscription exposes a PaymentIntent property, and you use that PaymentIntent in conjunction with your frontend code using stripe.js to walk the customer through authenticating the payment, and that activates the subscription.
the subscription is trialing — if the subscription doesn't involve an initial payment, like when using a trial period for example, you can also check if the subscription has a pending_setup_intent. You can use this on your frontend to have the customer complete a 3D Secure authentication, so that future payments(like the first one after the trial) are more likely to successfully claim an exemption and not require having the user authenticate at that point.
You can also instead use Stripe Checkout to easily collect payment details and set up a customer and subscription for you, while also handling any initial authentication that's needed : https://stripe.com/docs/payments/checkout/server#create-subscriptions
As for the recurring payments, Billing can handle that for you. You can configure you settings to automatically email the customer to complete 3D Secure if it's encountered on a recurring payment. So you can absolutely build an SCA-ready solution with the subscriptions API on Stripe.