What's the right way to schedule multiple future payments without consistent intervals with Str-CodePudding

I am trying to achieve the following: set up future payments that don’t have a consistent interval (for example, a payment now and a payment on 2 more pre-set dates). I have an object of dates and amounts and I am creating a subscription for each that I cancel before a second charge is made.

const _payments = stripePayments.map(async (payment) => {
  try {
    const price = await stripe.prices.create({
      unit_amount: payment.amount * 100,
      currency: 'usd',
      recurring: { interval: 'year' },
      product: process.env.SCRIPE_PRODUCT
    })

    const subscription = {
      customer: customerId,
      items: [{ price: price.id }],
      billing_cycle_anchor: payment.dueDate,
      cancel_at: addYears(new Date(payment.dueDate), 1)
    }

    return await stripe.subscriptions.create(subscription)
  }

  catch (error) {
    throw new Error('creating Stripe subscription failed '   error)
  }
})

I have 2 questions:

Is there a better way to do it?
In the billing I see a small charge made right after the subscription. Why is that? Is there a way to remove it?

CodePudding user response：

Subscriptions aren't a good fit if you're dealing with inconsistent billing intervals, as Subscriptions are designed to automatically process payments on a recurring basis based on consistent billing intervals. Leveraging Subscriptions will also result in there being more objects that you need to maintain and clean up.

The code you shared will do more than process a payment in the future. When setting billing_cycle_anchor during the creation of a Subscription, the resulting Subscription will immediately process a prorated payment for the portion of the Subscription before the billing_cycle_anchor date and then process another full-price payment on the billing_cycle_anchor date. (source)

Stripe has a process that allows you to collect a payment method, then use that payment method to make a payment at a point in the future. You can view the full guide on that here.

The drawback with the above approach, is that it requires you or your system to make the request to create/process the Payment Intent when you want to process a payment in the future. If you need a way to schedule these payments to occur in the future, then Subscription Schedules are the best option as they allow you to schedule the creation of Subscriptions. However, Subscription Schedules can be a bit tedious to work with, and still result in Subscription objects that you need to maintain and clean up to ensure they don't generate any unexpected payments. I would recommend using the process linked above instead of Subscription Schedules for these reasons, but below are some useful resources if you decide to work with Subscription Schedules.

Additional context is needed regarding your second question to understand what charge you're referring to.