#jose-fernndez_api

1 messages · Page 1 of 1 (latest)

candid domeBOT
#

👋 Welcome to your new thread!

⏲️ We'll be here soon! Typically we respond in a few minutes, but sometimes we might take a bit longer if the server is busy or if you have a particularly tricky question.

⏱️ We close idle threads, which makes them read-only. Once a thread is closed it won't be reopened, but you can always start a new thread if you have another question.

🔗 This thread will always be available, even after it's closed. You can find it again using Discord's search, or you can save this link: https://discord.com/channels/841573134531821608/1498313710702297209

📝 Have more to share? Add more details, code, screenshots, videos, etc. below.

lost badge
#

Hi. So in your example, would you want the customer to be charged the full amount when they subscribe at 10:00? Or a prorated amount?

blissful aurora
#

Hello, thanks for following up.

In our case, we expect the charge to be prorated.

The idea is for users to pay for access only up to a fixed daily cutoff time (for example, 14:00 UTC). Therefore, if a user subscribes at 10:00, they should only be charged for the time remaining until 14:00, rather than the full daily amount.

Subsequently, we expect the subscription to renew in full daily cycles aligned with that cutoff time (14:00 → 14:00).

Our primary goal is to ensure that:

All billing cycles are aligned with a fixed daily cutoff time.
The initial charge is proportional to the remaining time in the current cycle.

Could you please confirm whether this behavior is possible?

Thanks in advance.

lost badge
#

Ah ok yes this is possible. You'd want to create the subscription and set billing_cycle_anchor to the cutoff time

#

Default behavior is to prorate in this scenario

blissful aurora
#

I have a few follow-up questions to make sure this works well for our use case:

  1. Daily subscriptions + billing_cycle_anchor
    We plan to use this with daily subscriptions.
    Are there any limitations or known issues when using billing_cycle_anchor with a daily interval (e.g., frequent invoicing, proration edge cases, or payment reliability concerns)?
  2. Handling past_due subscriptions
    In cases where a subscription goes into past_due and all retry attempts fail:
  • What is the recommended approach to handle this?
  • Should we cancel the subscription, pause it, or leave it in past_due until the user updates their payment method?
  • Is there a best practice to “restart” the subscription cleanly once the user wants to pay again?
  1. Payment retries configuration (dunning)
    We’d like to better understand how to configure payment retries:
  • Can retry logic be customized based on the subscription interval (e.g., different retry behavior for daily vs monthly subscriptions)?
  • What’s the recommended retry strategy for very short billing cycles like daily subscriptions?
  1. Recommended approach for daily billing
    Given that we are working heavily with daily subscriptions aligned to a fixed cutoff time, do you recommend using subscriptions in this way, or would Stripe suggest a different billing model (e.g., one-time payments or another approach)?

Any guidance or documentation you can point us to would be greatly appreciated.

Thanks again for your help.

lost badge
#

  1. No none that I can think of provided you're setting this timestamp correctly.

  2. This is completely up to you. Depends on the behavior you're looking for. Different merchants handle this differently depending on what they want. You can automate some of this behavior in your dashboard settings at: /settings/billing/subscriptions

  3. It can't be customized differently for daily and monthly subs unfortunately. There is no recommended strategy. Again, it's whatever works best for your use-case

  4. I think it makes sense to use subs here since you are billing on a fixed interval