PreviewSubscriptionUpdateRequest

Send at least one of amount, interval, intervalCount or nextPaymentAt. A request that changes none of them is rejected, because there is no difference to price.

The figures come from the same calculation the update endpoint runs, and the same rules reject the same requests, so a preview that returns a settlement is one the update can apply.

amountinteger<int32>

Amount intended to be collected by this payment. A positive integer representing how much to charge in the smallest currency unit (e.g., 100 cents to charge 1.00 USD).

Example: 110

intervalSubscription-Interval

Subscription interval. The minute and hour intervals are only available in test mode.

Enum Value	Description
minute	Minutely
hour	Hourly
day	Daily
week	Weekly
month	Monthly
quarter	Every three months
year	Yearly

Possible values: [minute, hour, day, week, month, quarter, year]

Example: month

intervalCountinteger<int32>

Number of intervals between subscription payments.

Example: 1

nextPaymentAtinteger<int64>

The date when the next payment will be made. Measured in seconds since the Unix epoch.

Send it on an update to move the next charge without changing the price. The date must be in the future and no more than five years ahead, and the subscription must be active or past due with a live schedule. A trialing subscription moves with trialPeriodEnd instead, and a paused one has to be resumed first.

A pending skipIntervalCount, pauseIntervalCount, pauseAtPeriodEnd or cancelAtPeriodEnd blocks the change, because it would turn the charge at the new date into a skipped, paused or cancelled cycle instead of a payment. Clear it in the same request by sending 0, null or false for that field.

Moving the date on its own settles no money. Combine it with prorate to charge or refund the time that moves.

Example: 1636366897

PreviewSubscriptionUpdateRequest

{
  "amount": 110,
  "interval": "month",
  "intervalCount": 1,
  "nextPaymentAt": 1636366897
}