Production subscription locked after removing a scheduled plan change — HTTP 500 on subsequent SwapPlan

Questions
1

We’re testing subscription billing for a SaaS web app before launch and have encountered a locked production subscription.

Here’s the sequence:

  1. Registered and paid for our Basic plan at $19/month.
  2. Upgraded immediately to Advanced at $34/month. Our application collected a separate prorated payment and used SwapPlan to schedule Advanced for the next renewal.
  3. Chose to downgrade back to Basic at renewal. Our application deleted the scheduled SWAP_PLAN action successfully. Advanced access remains available through the paid period.
  4. Selected “Keep Advanced Plan,” which calls SwapPlan again to restore Advanced for the next renewal. That request failed.

At October 2, 2026, 19:57:25 UTC, Square returned:

HTTP 500
INTERNAL_SERVER_ERROR
Subscription ID [available privately] is locked and is not billable.
Please retry or contact support.

RetrieveSubscription still reports:

status: ACTIVE
plan_variation_id: our Basic plan variation
charged_through_date: 2026-11-02

No new charges or refunds appeared during the downgrade or failed restoration attempt.

We reviewed this similar case. Importantly, our downgrade code explicitly selects only the SWAP_PLAN action for deletion. It does not delete all returned actions or any CHANGE_BILLING_ANCHOR_DATE action.

We have stopped retrying changes. Could your Subscriptions team please:

  • Investigate whether this is a temporary processing lock or requires manual intervention.
  • Clear any stuck internal lock or invalid action state.
  • Confirm whether the November renewal could be affected.
  • Confirm the supported procedure for withdrawing and later restoring a scheduled plan change without causing this issue.

Please do not initiate a charge, cancel the subscription, or create a replacement subscription while investigating.

I can provide the production subscription ID and additional diagnostic details privately to Square staff.

Thank you!

Followup:
I found related topics #27488 and #28009. Our implementation selects only SWAP_PLAN actions for removal; it does not delete CHANGE_BILLING_ANCHOR_DATE actions or indiscriminately delete all returned actions.

Could your Subscriptions team inspect subscription 814a2922-00c9-42b5-bf5d-b0e5f9a39ad4, identify the request that triggered its lock, check for any remaining billing-anchor actions, and repair/unlock it? Please also confirm its next renewal will bill the intended plan correctly.

We have paused further plan-change testing pending your guidance.