#ben-checkout-variousproducts

1 messages · Page 1 of 1 (latest)

empty eagleBOT
main scarab
#

ben-checkout-variousproducts

#

@fading prawn there isn't really a way to do the second one cleanly, we don't support this. I would do a one-time Price and that's it, no "limited time" concept

fading prawn
#

so our issue is, this product must give the end-user access to the platform for that pperiod. So if they buy a 100 day plan, they must have access to the platform for 100 days

#

Our customer can create the product on our platofrmi ndays, weeks and months

main scarab
#

I understand, but we don't support this. We don't have this notion

fading prawn
#

There mst be a way of doing it as our competitor does it

main scarab
#

There's no way I can think of on Stripe with Checkout to do this no

fading prawn
#

So lets say our customer enters 100 and selects days. Could we not cerate a price that is interval: day, interval_count: 100, and then set cancels_at 100 days from now?

With product 3 I assume we could do hte same, with a sub schedule, and setting end_behaviour to release

#

so phase 1 would be the one-time payment, phase 2 would be the follow up recurring sub, and it would roll into recurring upon phase end

main scarab
#

one-off payment for a limit period (like a time limited subscription)
you said this. Why would it switch into recurring after? I thought you wanted it to fully end?

fading prawn
#

So there are 2 scenarios. Soem context: our platform is for coaches to sell coaching plans to their clients. They may sell you a 10 week plan, like 'Summer Body 10 week Challenge' for example, where you as a customer will onyl be a custoer for 10 weeks.

But they may also sell a monthly coaching plan, but the first 3 months mst be paid upfront. So 'Monthly coach plan' is £100pm, with £300 upfront and then £100pm after the intial 3 months

#

These are 2 scenarios where a one-off payment is required in relation to a time limited product / service

empty eagleBOT
main scarab
#

Sure, but for now I was talking about the first example, which was the second example in your first question. That one is not really possible to "model" in Checkout unless you do a normal one-time Price

fading prawn
#

I am unsure how our competitors are doing it in stripe then.

#

this: Could we not cerate a price that is interval: day, interval_count: 100, and then set cancels_at 100 days from now?

#

would this not work?

main scarab
#

I'm really sorry it seems like we might be talking about different things. You started talking about Checkout and how it presents the price to pay in the UI. This is before you use cancel_at (which Checkout does not support at all). But now you're saying cancel_at works fine.

#

I have to run and @dense burrow is taking over but I think it'd be important to clearly explain your issue for one specific case at a time right now

fading prawn
#

sure

#

@two-shoes please let me know once you've read the history

dense burrow
#

Can you give a summary of a specific case that you're hoping to work through? Preferably with the steps you're currently taking and the end-goal

fading prawn
#

so our platform allows coaches to create and sell products to their clients. We use stripe connect for this.

We allow the coaches to create 3 products:

  • recurring packages, e.g. monthly coaching at £100pm
  • one-off packages, e.g. a 10 week plan for £250 that ends after 10 weeks (client ceases to be a customer of the coach)
  • recurring packages with an upfront fee, e.g. monthly coaching with a minimum 3 month upfront payment. So £300 now, then £100pm thereafter

I am trying to understand how best to create these and present them to the client.

Our platform msut allow access for the client for the period they pay for, so subscriptions seems to be the way to do this.

We were previously advised that if we creats a price that is for a product that last 100 days, to create the price with interval: year, interval_count 1 and when creating the sub set cancels_at to be 100 fays from now. Although this works... it presents to the client at checkout as a 1 year plan

dense burrow
#

We were previously advised that if we creats a price that is for a product that last 100 days, to create the price with interval: year, interval_count 1 and when creating the sub set cancels_at to be 100 fays from now. Although this works... it presents to the client at checkout as a 1 year plan
When are they charged for the 100 days? Just once? Or is there a billing cycle?

fading prawn
#

If it is example 2 in the abobve, just once. They are a customer for 100 days only and their plan will end.

dense burrow
#

Right, but when do they pay?

fading prawn
#

They pay before they get access. So the coach onboards them which sends them a checkout link. The client pays. We listen for the hook and then create their plan

dense burrow
#

So it's just a single payment that's good for 100 days. Do you want them to be converted into a regular subscription after? Or does it just drop off and nothing happens after 100 days?

fading prawn
#

For examplew 2 above, no, they should just drop off after 100 days.

For example 3 above, yes, they should then move to a recurring product.

dense burrow
#

I think it would make more sense to have just a one-off payment for the 100 days in example 2. Like, there's no way to hack Stripe into thinking there's a single 100 day billing cycle without showing your user that they're actually on a yearly/daily billing cycle that cancels itself after 100 days.

As for example 3: you can achieve this with Subscription Schedules, but you'll likely run into the same problem: https://stripe.com/docs/billing/subscriptions/subscription-schedules

Your best bet here would be to create a totally white-gloved UI where the user never sees any of the Subscription updates via a Stripe UI. You would build a custom UI that only shows them what they need to see, along with a system that can track the days until cancellation to display to the user.

Subscription schedules

Learn how to use subscription schedules to automate changes to subscriptions over time.

fading prawn
#

ugh so we couldnt redirect to stripe and handle the checkout there?

#

setting aside that the end user would see per 100 days at checkout, is the above viable though?

dense burrow
#

Yeah, that should be fine if you don't mind them seeing the billing cycle as it is

fading prawn
#

Im curious to know how our competitor has achieved this, unless they are using direct charges and are handling the subscription internally only

#

The reason i wanted to use subs, as natively it handles periods for us and we can just tie into the hook when the sub ends

#

unless...

#

what if we created the product as a direct charge, but post checkout, on our redirect, we create sub with another price that is dedicated to one-off plans. That sub has no value and will not recurr. The duration (start to cancels_at) is equal to that in the plan purchased. So they have made a one-time payment and checkout is as expected, but behind the scenes we have still subscribed them

#

this sub is created both in stripe and our platform (on hook receipt)

dense burrow
#

So you'd essentially create a "dummy subscription" that only suits to help you track their time on the product?

fading prawn
#

yes

dense burrow
#

That could work, but it feels flimsy. Like, you're going to be generating a lot of subscription and invoice events for that dummy subscription. That being said, it sounds like it could work. I don't see any reason why not

fading prawn
#

flimsy is certianly one way to describe it

#

I'll have to have a play with it. I want to avoid creating a white gloved checkout if I can. Its just a PITA.

#

Thanks two-shoes, this has been a useful pairing process!

dense burrow
#

Sure thing! happy to help, even if we didn't get to a suitable conclusion. Let us know if you have any other questions