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.
Related
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.
I am trying to create a subscription system with PayPal for a user subscribe to a course. So far I have already made the billing agreement and this has no problems, but the problem is that I want each month or each time the subscription is paid, the user is automatically reenrolled, otherwise if it is not possible to charge (maximum 2 attempts) the subscription is canceled and they no longer have access to the course. This last part I have no idea how I could do it, basically I don't know how I can check the status of the agreement and cancel when it is not paid.
The current version of PayPal Subscriptions does not use "billing agreements". If you have integrated with billing agreements, that is the previous version of PayPal Subscriptions and you should discard that deprecated implementation and read the current documentation, which only uses: Products, Plans, and Subscriptions.
(Do not use Billing Agreements, and do not use the deprecated PayPal-Node-SDK. Use the Subscriptions API directly)
To receive notifications of when a Subscription is paid for or its status otherwise changes, integrate Webhooks.
Some other possibly useful information: How do you know if a user has paid for a 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.
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.
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