How to add a subscription add-on with immediate proration WITHOUT re-billing the base plan
Status: Closed · Asked by Victor Zertuche on · 0 views
Hi,
We're using PUT /subscription/{id}/upgrade-downgrade to let customers add an add-on to their existing subscription at any point in their billing cycle, without changing their plan.
Payload we send (same plan_id as the customer's current plan — we are not changing plans, only adding an add-on):
{
"plan_id": "23222d219q21231234252b7a6",
"customer_id": "66272321312323ce9ed2a060",
"payment_term": "net0",
"activated_at_val": "immediately",
"payment_mode": "credit_card",
"addons": [
{ "id": "234236215423421231223474", "quantity": "1" }
]
}
What we observed: the customer's card was charged (attempted) for $200 MXN, which is the full monthly plan price ($150) plus the add-on price ($50) — not just the add-on. Since plan_id didn't change, we expected only the add-on's prorated cost to be charged immediately, with the base plan continuing on its normal billing cycle.
Our question: is there a documented way to add an add-on to an existing subscription with activated_at_val: "immediately" so that only the add-on is charged now (prorated for the remaining period), while the base plan itself is left untouched and simply bills together with everything else at the next renewal — instead of the entire subscription (plan + add-on) being re-invoiced immediately?
Is plan_id required even when unchanged? Is there a separate endpoint or parameter set for "add-on only" changes that avoids re-prorating the base plan?
Thanks in advance.
Hello Victor,
Thank you for sharing the details.
Could you please provide us with the Invoice ID for the invoice created in this specific case? Alternatively, please share any relevant details, such as the subscription ID, customer ID, or the approximate date and time when the API request was made, that would help us locate the invoice.
Once we have these details, we will be able to investigate this specific case and better understand why the API behaved in this manner.
Hello Victor,
Following up on our previous reply.
Could you please provide us with the Invoice ID for the invoice created in this specific case? Alternatively, please share any relevant details, such as the subscription ID, customer ID, or the approximate date and time when the API request was made, that would help us locate the invoice.
Once we have these details, we will be able to investigate this specific case and better understand why the API behaved in this manner.