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.
Related
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
I am building a stripe integration for a client. The subscription has a 7-day free trial, following which the customer will be charged a fixed-amount every month.
I am familiar with the Stripe Subscription flow with SCA for subscriptions where the first invoice is paid immediately (and therefore SCA can be triggered on the client end for the current PaymentIntent during the customer sign-up flow), but I am unsure which is the best way to implement a solution where the first payment is not taken immediately.
The Stripe docs suggest setting up a SetupIntent instead, and then making a Merchant-Induced-Transaction (MIT), but this seems to be frowned upon and not completely compliant, not meant for dealing with free-trials? (https://stackoverflow.com/a/62456011/11868365)
SetupIntents are exactly what you'd use for Subscriptions with trial periods. That SO question you linked to is still correct, it's exactly what Stripe Checkout does in subscription mode with free trials.
When I create a subscription with stripe and the customer already has a default set payment method, I know how to confirm a card when it requires 3D Auth because I can look at the failure reason but what if a customer updates their card within the month...
How do I check if a new payment method requires 3D Auth when a customer already has an active subscription? And can I perform 3D Auth before the next subscription billing so it will work automatically without interaction?
You should use a SetupIntent to attach a card to a Customer (and also perform any authentication if required), when changing a Customer's card mid-cycle.
SetupIntent's will try to claim authentication exemptions for any future off_session payments (e.g. a recurring Subscription payment). There is still a chance issuing banks might still request authentication on the recurring payment, SetupIntent just try to reduce that chance, to address your point here:
And can I perform 3D Auth before the next subscription billing so it will work automatically without interaction?
In the case that the next recurring payment fails, you would have to bring your Customer back on session (to your payment page) and then authenticate the subscription.latest_invoice.payment_intent.client_secret with confirmCardPayment()
i want to implement SCA in my project.i would like to know whether SCA forces the user to complete 2 factor authentication while update,cancel,resume subscription.so i can handle the code accordingly.so far stripe didn't ask me.Thanks in advance.
SDA comes into play for authenticating online card payments. Stripe Billing has been updated to support SCA requirements.
You won't necessarily need to authenticate for all subscription changes (such as cancel or update) but you could for scenarios like a subscription signup, a card change on a subscription, or on a recurring charge on a subscription.
The following link describes the scenarios and tools you would leverage for Stripe Billing + SCA: https://stripe.com/docs/billing/migration/strong-customer-authentication#upgrading-integration
I've making a SaaS that allows customers to subscribe to a plan, and use coupons at the checkout stage. The coupons give the customers X% off for X months, and by default, everyone gets a 7 day trial when they subscribe.
What is confusing me is the documentation. In one section it says that you should create SetupIntents to take a payment and elsewhere it says to use tokens.
I'm in the middle of coding the payment flow, but I just wanted to check to see if my logic and understanding is correct. Could anyone validate the below?
Customer enters card number and coupon
Call Stripe, get token for card
Send token and coupon to server
Create Stripe customer with token
Create Subscription with discount and pass customer ID
What has now happened is an authorisation attempt was made. If SCA is required, then the subscription status is incomplete and the latest invoice payment intent status requires action.
At this point, I can redirect my user to the SCA Flow using handleCardPayment() to prompt 3DS, and once complete the subscription status is then active.
If the invoice payment fails for any reason, then the subscription state is incomplete and the payment intent requires has a payment action required status. At this point, I should present my customer with the React Elements form again, and call the stripe.invoices.pay endpoint with the new card token
Going forwards, all subscription charges should not need further SCA approval, however if the customer changes plan or the bank requests it, then I can point my user back through the SCA Flow process
A diagram of the flow is here: Green is UI, Orange is Server, Blue is Stripe
Is there anything I have missed or misunderstood here? I've been reading about creating SetupIntents and PaymentIntents, but I'm not sure I need this?
If you are creating subscriptions using the Stripe Billing product they handle creating the PaymentIntent(if you are taking a payment immediately) or a SetupIntent (if you are setting up a trial or metered billing). All that you really have to do different is handleCardPayment (for payments) or handleCardSetup (for setting up trials and metered billing). This section in the docs is pretty good.
If you are not using billing they have a video on their Stripe Developers Youtube channel which may help clear up any confusion.
Hope this helps :)
Welcome fellow sufferer, cards and tokens are implemented in Stripe Charges API which is not SCA compilant. If you want use Stripe for payments inside the EU you should use payment intents.
Card tokens are also allowed for creating payment intents.
But if you want reduce the number of necessary authentications you should use setup intents (with usage = "off-session") for creating payment methods and not card tokens.
I have a lot of old customers who have still registered with the Charges API. I use the following strategy:
New customers always register via Setup Intents and Payment Methods.
Old customers use the Charges API until their tokens become invalid. Then they must also use setup intents and payment methods.
Of course, the customers do not notice much of it.
In summary, I would always use payment methods and setup intents for new customers and card updates. Only with the setup intents can you ensure that your customers have to authenticate themselves as rarely as possible.
EDIT: The crucial point is off-session payments that occur with subscriptions. The Stripe procedure is described here: https://stripe.com/docs/payments/cards/saving-cards#saving-card-without-payment