#mounirmtl

1 messages · Page 1 of 1 (latest)

copper stumpBOT
#

Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.

frail cargo
brazen hearth
#

hmmm that's a good question. How does that work when you want subscriptions and one time purchase on the same invoice?

frail cargo
#

The one time prices will only be applied to the first invoice

brazen hearth
#
  1. So the process would be if checkout contains only one time purchases, we go with regular payment intents.
    And if it contains at least 1 subscription, we create a quote and wait for acceptation and activate the subscription when it is accepted?
#
  1. Would stripe charge us more for using the quote api that way?
frail cargo
#
  1. Yep that sounds like a good plan. You can also use Quotes for the one-time prices and then create an invoice for them if you want. Having a consistent path either way may make things easier.
  2. Unfortunately I am not really familiar with our pricing but you can ask our support team about this. If Quotes are an extra feature, you may be able to use our upcoming invoice endpoint to preview the subscription's price instead https://stripe.com/docs/api/invoices/upcoming
Stripe API reference – Retrieve an upcoming invoice – curl

Complete reference documentation for the Stripe API. Includes code snippets and examples for our Python, Java, PHP, Node.js, Go, Ruby, and .NET libraries.

copper stumpBOT
brazen hearth
#

Yeah invoices are an extra charge so we avoid them except for subscriptions since invoices are free with them.

#

Just so I don't ask again in 30min.
Assuming quotes are an extra charge, is there an alternative to delay the start of a subscription manually?

frail cargo
#

Otherwise it might just be easier to not create the subscription until it has been accepted. You can even backdate the subscription and change its billing cycle anchor if you want it to act like it has already been running for a bit

brazen hearth
#

It's not really about customer accepting a subscription.
It's more like payment_intent when we can create them and manually move on processing the payment.
So we have full control over the payment intent lifecycle.

And I was wondering if there's a way to have the same control over the subscription billing lifecycle when creating the subscription for the 1st time

#

Maybe subscription schedule is what I'm looking for.
Is there a way to cancel the subscription before the subscription even start when using schedule?

dreamy wasp
#

👋 taking over as pompey needs to step away soon

#

Is there a way to cancel the subscription before the subscription even start when using schedule?
This doesn't really make sesne.

Subscription (linked to a subscription schedule) gets created when the schedule actually starts

brazen hearth
#

How do you cancel a schedule

dreamy wasp
brazen hearth
#

Oh nice. Thank you

#

That's very helpful

#

The process would be:
Create a subscription with both subscription items and 1 time purchases.
Create a schedule for that subscription to start at the desired date.
Cancel the schedule if the subscription and 1 time purchases are canceled before they start. For example a merchant declining an order that would contain both subscriptions and 1 time purchases

dreamy wasp
#

I haven't looked at your previous messages yet but I don't understand this part

Create a subscription with both subscription items and 1 time purchases.
...
Cancel the schedule if the subscription and 1 time purchases are canceled before they start. For example a merchant declining an order that would contain both subscriptions and 1 time purchases

like the subscription starts as soon as it gets created in step 1

brazen hearth
#

Sorry, let me be more descriptive about our use case

#

We have a platform where merchants can create their own store and they have customers who buy items on those stores.

#

Those are fresh food orders.

#

An order is made ahead of time. Usually a week in advance. Merchants can decline or accept orders

#

We only charge the customer when a merchant accepted an order to avoid unnecessary payment processing fees.

#

Customers can also sbscribe to products alongside 1 time purchases like you can do on amzon.
For example, someone susbcribes to a dish to be delivered weekly but in the same order buy a 2nd dish for just 1 time.

#

So this order needs to be a subscription with an additional item in the subscription so they're in the same 1st invoice of the subscription

#

Now we'd like the subscription to start at the time the order has been scheduled (the week after). But we need to cancel the whole thing if the merchant declines the order

#

Does it make more sense?

dreamy wasp
#

reading and thinking..

#

do you need all these covered under just one subscription?
It might be relatively easier to create separate subscriptions for each "product"/"dish"

brazen hearth
#

How would that work?

dreamy wasp
#

ah nvm, I think I considered all products as recurring but you have a mix of one-time products too

#

ignore that

brazen hearth
#

Yeah not the simplest use case 😅

dreamy wasp
#

Okay so here's what you'd likely need (you'll want to test out in test mode to be 100% certain)

You don't need to call Stripe APIs until the merchant actually confirms the order in this scenario. Once they confirm it, you can call Stripe to

1/ Create a Subscription Schedule with the recurring product + one-time product
https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#start-subscription-future

2/ if merchant cancels the order, you call the API to cancel the schedule
https://stripe.com/docs/billing/subscriptions/subscription-schedules/use-cases#cancel-schedule-and-subscription