I have a number of users who are currently subscribers to a monthly subscription.
For business reason, I want to be able to
1) Charge the customer when he decides to subscribe to our plan
2) Let the subscription become effective a number of days after the purchase
Currently a charge is immediately attempted when a subscription is added to a customer in stripe.
I want to stick to the stripe subscription because a) I still want to have stripe to manage subscription for me in future dates, and b) I have written a lot of code for the subscription model.
Is it feasible at all to demarcate the charge/invoice and the subscription start date?
You can control the time when the subscription actually starts (i.e. when Stripe will start billing the customer) by using the trial_end parameter in your subscription creation request. Simply set the value of the parameter to the timestamp of the exact time you wish Stripe to start automatically billing the customer.
If I understand your desired payment flow correctly, you'd want to do something like this when a customer signs up:
Collect and tokenize the customer's payment information (using Elements or Checkout).
Using the resulting token, create a customer object and save the resulting customer ID in your database.
Create a one-off charge using the customer object for the first payment.
Create a subscription using the customer object and the trial_end parameter set to the time you want Stripe to start automatically billing the customer.
See https://stripe.com/docs/subscriptions/trials for more information about using trial periods.
This is possible now through Stripe Subscription Schedules. With that, you can create a one phase schedule that starts in the future. By default, this will start the subscription on the date you want, automatically renew, and charge the customer on the start date. Also by default, it will immediately perform a transaction to pay for the subscription.
I found the required iterations to be a bit confusing. Essentially that is a multiplier against how many times the original price's interval repeats before moving on.
If all you want to do is start a subscription price in the future, use the Subscription Schedule API call. Create an items array of 1. Set the price_id of the price, the iterations on that item, and the start_date to the unix timestamp you want to start the subscription.
Stripe has different use cases for subscription schedules. The first one they list is exactly this purpose, starting and charging a subscription on a future date. Look through them if you want to adjust some more, like making the first phase a trial period instead.
Related
I know I can pre-auth a stripe subscription with a trial period. I want to pre-auth the 2nd, 3rd, 4th, nth subscription payment. The info we are sending out is time critical and if their subscription lapses due to NSF or something else, it would be nice for them if they could rectify the problem BEFORE it lapses.
There is a pending invoice you can get for a subscription, and you can create a payment intent with an invoice ID so that when the invoice is paid, the payment intent (that captured the money) will be used to collect the money. BUT the pending invoice doesn't have an ID until one or 2 hours before they try to collect the money which is 3-4 days too late.
Has anyone figured out how to pre-auth subscription payments other than the first one?
Is there a subscription engine I could use (with stripe/paypal/venmo) that would mean I could quit using the deficient stripe subscription system?
Subscription invoices don't exist until the renewal of the billing cycle, and the underlying payment intent is created by the invoice. It's not supported to "pre-auth" subscription payments. Instead, you need to handle payment failures when those occur, optionally by letting Stripe handle that for you.
If you want to have successful payment in advance of some time-sensitive event, then I'd suggest one of two alternatives:
Shift your billing cycle to invoice 3-4 days ahead of what you have set now, allowing you time to recover from payment failures before the delivery timing.
Alternatively you would implement your own recurring payments using saved payment details. You would similarly want to authorize the payment ahead of time to allow for recovery. You could optionally use manual capture to defer capture until the time of delivery.
We are using Stripe subscription. In that if a user creates a Product then they can set the price suppose $9.99.
If the other users wants to subscribe the same product they have to pay $9.99. From the paid $9.99, the admin will get 2% and (2.9 + 0.30)% Stripe fee will be deducted and the remaining amount will be sent to the product creator's connect account.
The issue is if the user subscribe a product, a charge is created and the amount deducted from the subscriber. Then the invoice will generate and that time, again the amount will deduct from the subscriber a/c. Double time payment cuts from the subscriber's account.
I'm using destination-charges method to apply the charge and transfer the amount to creator's connect account for any subscription in the invoice.payment_succeeded webhook's method.
How to prevent 2nd time payment deduction?
enter image description here
Creating a subscription will generate an invoice that will charge for the upcoming period(they are charged in advance, so if you had also done a destination charge before creating the subscription, you are charging the customer twice — I assume that's what you mean?
What you probably want to do here is one of :
instead of doing a one-off destination charge or doing a transfer manually from a webhook handler, just set the application fee on the subscription so it's deducted from the invoice instead, by setting the destination of the funds and the application fee you keep :
https://stripe.com/docs/billing/subscriptions/connect#transfer
https://stripe.com/docs/api/subscriptions/create#create_subscription-application_fee_percent
if for some reason that is not an option and you still need to do a separate charge than the first invoice, maybe create the subscription with trial_end set until the next billing date, which will skip the first payment (sine you already processed it)
https://stripe.com/docs/api/subscriptions/create#create_subscription-trial_end
suppose i have a membership service which cost $10/month in a subscription way
but some users can not have a reusable source to make a subscription via plan api ,alternatively i will let him to do an one-time payment via order api.(at least accept one month's money)
it is the same product,same amount,difference is one is for plan,another is for order,so question is, should i create two products one is goods type(for order),one is service(for plan/subscription). or one service type product is enough?
As a concept in the Stripe Dashboard, product SKUs are only used for recurring plans or invoicing. Any one time purchase can just be a charge, and does not need to be associated with any "Product" within your Stripe configuration.
If the product in this case is literally just one month of the plan, then you should probably use the same Product you have specified.
If the payment method will only work once, you could do nothing, and when the first period is up, and Stripe tries to renew, the payment will fail and the subscription will be canceled.
Or, if you're positive beforehand that it should only be charged once, you could cancel the subscription right after the first payment is completed. The customer would still have an active subscription for the period they paid for, but Stripe would not try to charge them automatically when that first period expired.
I need to be able to handle two types of subscriptions that Stripe doesn't seem to support out of the box:
A lifetime subscription
A two-year subscription
Lifetime subscription is easy. I'll just create a single charge and be done with it. It would've been nice to have a subscription record that I could check for validity.
Two-year subscription is where I am not sure what to do. I figure I'd create a one year subscription (current max in Stripe) and will have to use web hooks for when a new invoice will be generated. What would be the proper way of cancelling an upcoming charge? I am also worried that customers will receive an email alerting them for an upcoming charge in the middle of the period. Any way to avoid this?
Thanks in advance!
Stripe's subscriptions do not have a set end date. The 1 year maximum that you mention is the maximum interval, i.e. the frequency at which the customer will be billed.
If you want to end a subscription after a set number of payments, your best bet is to use webhooks to count the number of successful payments (via the invoice.payment_succeeded events) and cancel the subscription when the desired number of payments has been reached.
Stripe does not send emails to customers about upcoming charges. It can optionally send email receipts after a charge is created, but you can disable this from your dashboard.
I have a web service which publishes and hosts certain information for my users. Each user's editing interface is separate from the information they've published. I'm billing for it using Stripe subscriptions, but I'm having trouble coming up with a workable way of handling unpaid subscriptions. Here's the logic I want to implement:
Upon the first failed billing attempt, my app should lock down the user's editing interface; instead, it should present them with a page with options for resolving their payment problem. However, information they've published will still be published, so a late payment doesn't interrupt things for their visitors.
Upon the last failed billing attempt, 15 days later, my app should remove information they've published as well. At this point, the user's editing interface is replaced with one that allows them to either re-activate their account with a new credit card, or completely delete the account.
If the user chooses to re-activate the account, they should not get a trial period
If the user re-activates, they should also have to pay for the 15 days they previously skipped out on, either by having their first billing period shortened by 15 days or by having a charge equal to 15 days' service added to their first bill.
#1 and #2 are very easy to implement if I watch for the right webhooks—just redirect requests for a delinquent customer, or a customer with a deleted or unpaid subscription, to a "fix this problem" page. #3 is pretty easy too—just create the subscription with trial_end set to now.
It's #4 that's tricky. How do I determine exactly how long the user's last invoice went unpaid before their subscription was canceled? How do I shorten the first billing period of the new subscription? Alternately, how do I pro-rate the customer's last invoice total to represent the portion that I actually provided to them, so I can add that amount to the new invoice? (I know I can create an Invoice Item to charge for the amount before I start the new subscription, so at least that's a possibility.)
Finally, does Stripe's "Mark Subscription Unpaid" option help with any of this? It looks like it keeps creating invoices but doesn't try to charge for them; I don't think that's what I want here.
You can definitely do all of that with Stripe's subscriptions. As you mentioned, the first two questions should be solved with webhooks. You would listen for invoice.payment_failedon your end to detect when a payment fails and immediately block you UI asking your customer to update their card details.
To update their card details you can use Stripe Checkout and just not set the data-amount parameter so that it doesn't display a price to your customer. Here is an example for this:
<form action="/charge" method="POST">
<script
src="https://checkout.stripe.com/checkout.js" class="stripe-button"
data-key="pk_test_XXXX"
data-image="/square-image.png"
data-name="Demo Site"
data-description="Update Card Details"
data-panel-label="Update Card Details"
data-label="Update Card Details">
</script>
</form>
Each time your customer tries to update his card, you would use the Update Customer API and pass the new card token in the card parameter. This will delete the default card on the customer and replace it with the new one. It will also try and pay the latest invoice of each subscription in the "Past Due" state. In your case it means that the latest invoice still in retry mode will be attempted to be paid. This does not count as a retry and can be seen as independent. If it succeeds, you just reenable the UI otherwise you continue asking the customer to update his card details.
When you reach the fourth failed payment you will get a customer.subscription.canceled if that's what you set up in your retry settings in the dashboard. You can detect that it's an automatic cancelation by checking the request key on the event and making sure it's null. In that case you block the UI/account completely for your customer.
For the last 15 days, if I understood your flow correctly, the customer hasn't really been able to use your application since you locked down the UI partially. But if you still want him to pay for that amount, you should store in your database that the customer owes you $X for the 15 days he couldn't use the subscription.
Later on, your customer finally comes back and want to reenable his account. At that point you inform him that the payment flow will restart from today and that you will charge him for the extra 15 days he missed before. To do that, I would use Invoice Items which will allow you to add an extra amount to the first invoice automatically. You would follow those steps:
Create the invoice item for $X for your customer.
Create a new subscription to your plan setting trial_end to "now" in case you have a trial period set by default on your plan.
This will automatically create the first invoice for the plan amount and add the invoice item created before.
Another solution here would be to reopen their latest closed invoice that wasn't paid and use the Pay Invoice API. When this happens you know your customer paid you for a full month now instead of just the 15 days he owed you. In that case you would create a new subscription and set a trial period of 15 days so that he starts paying again after that trial.
I wouldn't use the "Mark as unpaid" option here because you completely lock the customer out of your application. This feature for me is to be used when you let your customer use your application and plan to charge him in a few months for each of the invoices. This would be used for an electricity provider for example who would keep your electricity on for multiple billing cycles and continue to try charging you for each invoice.
The amount your customer really owes you in that case is dependent on the number of retries you allow and the days between each retry. What you can do here is use the created value on the invoice and compare it to the current time when you get the customer.subscription.canceled to determine how much time passed and calculate the proration of how much your customer owes you at that point.