PATCH /subscriptions/{id} with subscriptionPlanId (a real price increase), applyImmediately:true, prorate:true, and invoiceImmediately:true all explicitly set returns 200, with scheduledUpdate:null and the plan/basePrice updated immediately — but no new Order is ever created for the proration.
Repro:
- Active subscription with a valid payment mandate (card on file).
- PATCH /subscriptions/{id} {subscriptionPlanId:
- 200 OK, subscription correctly shows the new plan immediately.
- GET /orders (polled right after, and again 25+ seconds later): no new order appears — only pre-existing orders from before this call.
Tested twice, same result: once through our own integration code, once with a raw PATCH bypassing our code entirely on the same subscription, to rule out anything on our side. The subscription's mandate is present and valid (mandate.maskedIdentifier set) — not a missing-payment-method issue.
Per the docs, invoiceImmediately:true should "generate and charge an invoice immediately for proration" when applyImmediately and prorate are both true. Right now it silently does neither — the plan change applies, but the proration is never billed at all (not even deferred to the next renewal invoice, which is the documented behavior for invoiceImmediately: false).
Side note found while testing the opposite direction (a price decrease with applyImmediately:true): got a 422 "the prorated credit would exceed the new charge" — that's working as expected, just not documented in the OpenAPI spec's Proration/Timing section. Worth adding there too.
Fixed: an immediate subscription update with prorate: true and invoiceImmediately: true now creates and charges the proration order. The order isn't created during the API call itself. It's created in a short billing window afterwards, currently 15 to 30 minutes, and you'll receive the usual order webhooks when it's created and paid. We're documenting this timing in the API reference (along with the negativeProration 422) and looking at shortening the window for immediate invoices.
Correction to the above:
- There is no order-created webhook. You receive
order.paidororder.payment_failedonce the charge settles. - The window can be longer than stated: up to about 40 minutes after the PATCH in the worst case. We're shortening it.
- In test mode, SEPA debits don't settle on their own. Use the simulate-payment test helper to mark them paid or failed. Test card payments settle immediately.
invoiceImmediately:true does not generate or charge any order on an immediate subscription update
-
Sander moved item to board Live
1 week ago -
Sander moved item to board In progress
1 week ago -
Sander moved item to board Planned
1 week ago -
RAHANETRA Jason moved item to project Bugs
1 week ago -
RAHANETRA Jason created the item
1 week ago