In Stripe's UI there's the REASON column:
As per Stripe's docs, it's possible to cancel a subscription via API:
var stripe = require("stripe")("sk_test_J7rbZuZ0bLvmPVnuEKPFnIEC");
stripe.subscriptions.del('sub_49ty4767H20z6a');
Now, how can I pass the cancellation reason (provided by a user) to Stripe's API?
While it is possible to cancel subscriptions you cannot currently set a reason.
The reason displayed in the Stripe Dashboard is a (currently) internal-only cancelation code of either "Unpaid" or "Canceled".
"Unpaid" when the subscription has been canceled due to failure to collect payment by Stripe Billing's engine, or "Canceled" when you, the admin user, has manually marked the subscription as canceled.
FWIW, you could add this as metadata against the subscription object. Metadata is available on most objects in Stripe with key/value pairs: https://stripe.com/docs/api/subscriptions/object#subscription_object-metadata
Related
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.
How to enable users to update their subscription's payment method using Stripe Elements?
I couldn't find any reference to this neither in the docs nor on Stackoverflow.
This is how I'm currently setting the default payment method when the user first subscribes to our service.
Create a Stripe subscription object
Render the React CardElement component.
On submit, I call the browser's side Stripe library with stripe.confirmCardPayment(cardElement)
This then triggers a invoice.payment_succeeded webhook event.
In the webhook event, I get the payment intent ID which I use to retrieve the payment intent object which has the ID of the payment_method attached to it.
I then update Stripe's subscription object to use the successful payment_method's ID as the default payment method.
Is there a way to update the subscription's payment method without making a payment_intent first? Link to docs would be appreciated.
Thank you
You can use SetupIntents to save a customer’s card without an initial payment : https://stripe.com/docs/payments/save-and-reuse-cards-only [until step 4]
Listen for the setup_intent.succeeded webhook event to know when the SetupIntent is successful since the customer could close the browser window or quit the app before the stripe.confirmPayment callback executes.
Update the Subscription to use the resulting PaymentMethod ID as the default payment method.
Alternatively, you could also make use of the Customer Portal to allow customers to update their payment method for a subscription : https://stripe.com/docs/billing/subscriptions/customer-portal
I've got a test subscription set up that is active. I'm trying to test what happens when the payment fails. I need to be able to pass some metadata (cognito user ID) to the webhook endpoint, I think I know how to do this but can't work out how to test it.
Using the test webhook doesn't work because it sends a fake charge ID. I've tried using the payment failure card but not having much luck as it doesn't seem to be triggering my endpoint.
Here is what I've been reading already:
https://stripe.com/docs/billing/testing
Stripe charge after subscription, get metadata from subscription
Stripe subscription webhooks missing metadata and client_reference_id
How can I test subscription renewal flows in stripe?
Getting charge.failed event, but struggling to associate this charge to subscription, because the charge has customerId and the customer has a list of subscriptions.
Now I think below code can help
From event can get charge id and then retrieve charge obj with 'expand' property.
params := &stripe.ChargeParams{}
params.AddExpand("customer")
params.AddExpand("invoice.subscription")
ch, err := charge.Get("ch_3K4yJG2eZvKYlo2C14TZsir9", params)
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