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.
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'm integrating Stripe Subscriptions in our workflow, but when creating a subscription with a Customer created with a paymentMethod instead of source I receive the error This customer has no attached payment source.
If I call in the browser createToken() and attach it to the customer in the source field it works.
We integrated one-time payments using the new docs with SCA that use createPaymentMethod() and not createToken(), so our customers are saved with paymentMethod, not source, like explained here:
https://stripe.com/docs/payments/cards/saving-cards-after-payment#save-payment-method
curl https://api.stripe.com/v1/customers \
-u sk_test_secret_token \
-d payment_method="{{PAYMENT_METHOD_ID}}"
Furthermore, in the migration guide it says to replace createToken() with createPaymentMethod().
In Scenario 2: Charging customers off-session for their initial payment, I saw the following:
To create subscriptions and charge customers off-session for their
initial payment, you need to:
1) Use CreatePaymentMethod to collect payment information
2) Create a customer using the ID of the PaymentMethod you created
3) Create the subscription
4) Set up error handling using handleCardSetup for authentication failures and handleCardPayment for authorization failures
I followed those steps. I don't create a SetupIntent (just like I don't create it in one-time payments and it works in these cases), and receive the error I said before when trying to create subscriptions.
Is it possible to create subscriptions with a customer with paymentMethod instead of source?
(We reuse cards using the customers created with paymentMethod for one-time payments, so it would be very important to be able to reuse the same customer/card for subscriptions, without the need for the user input data in stripe elements or anything of the sort, because it would break our flow for reusing cards)
I was able to solve it by including the payment method in the field default_payment_method.
This field is described as follows:
ID of the default payment method for the subscription. It must belong
to the customer associated with the subscription. If not set, invoices
will use the default payment method in the customer’s invoice
settings.
So I assumed that it would use the payment method I associated with the customer when not defined. It seems it is not happening, tough, so I needed to pass it explicitly (is it a Stripe bug? or creating the customer with paymentMethod doesn't make it the default payment method in the customer’s invoice settings? I will contact Stripe to make sure).
Update (2019-09-23)
I contacted Stripe asking if this was a bug and they replied:
[...] With that being said though, this wouldn't be a bug on our end, rather
expected behavior.
If you're wanting for the Payment Method that you're adding to the
customer object to be used on subscriptions, or invoices, by default
without specifying the default_payment_method when creating the
subscription then you would want to attach the Payment Method and
specify the invoice_settings.default_payment_method parameter when
updating the customer. This information can be found within our API
reference here:
https://stripe.com/docs/api/payment_methods/attach
The parameter to use when updating this can be found on the customer
object itself, here:
https://stripe.com/docs/api/customers/update#update_customer-invoice_settings-default_payment_method
This can also be specified upon customer creation, which can be seen
here:
https://stripe.com/docs/api/customers/create#create_customer-invoice_settings-default_payment_method
Specifying this parameter would indicate that the card being added
would be the default for subscriptions, as well as invoices, so that
the default_payment_method wouldn't need to be specified upon the
subscription, or invoice, creation.
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.
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
I am trying to create a basic subscription service on my site and I am not sure of a standard way to deal with subscriptions. I'm sure I could hack something together but I'm just wondering if there is a suggested way.
So I have created a billing plan and activated it.
I have a subscribe button on my site that creates a billing agreement referring to the billing plan created in step 1 and redirects the user to the PayPal website were they can login and accept the subscription.
Once the user completes the actions on the PayPal website they are returned back to my site with a token were I then execute the agreement using the returned token from PayPal as per the documentation.
So I guess after these steps the subscription is created for that user, is active and the first payment is made immediately.
In my database, I have a field for each user names subscribed and it's value is a boolean which I set to true once they are returned to my site and the execute command is successful.
My problem is keeping this boolean value up to date for each user as this is the value I check to see if they can access the content.
Canceling - I can provide a cancel button on my site to cancel their subscription and when successful I can set the value to false. But what if they cancel through the PayPal website? I think there is a webhook names BILLING.SUBSCRIPTION.CANCELLED which may send me the agreement ID and If I save it in my database I can see which user it belongs to and set their subscription to false.
After the first month has passed and the next payment is due, is there a webhook sent for a successful payment or a failed payment so I can then set the subscription value accordingly? I see there is a webhook named PAYMENT.SALE.COMPLETED but I don't know if this fired for a successful payment and PAYMENT.SALE.DENIED for a failed payment. If these webhooks exist for subscriptions I imagine it should be a simple solution to keeping this subscribed value up to date.
Hope this made some sense.