Production subscription is "locked and is not billable" after DeleteSubscriptionAction on a SWAP_PLAN action — request to unlock

Hi Square team,

One of our production subscriptions (Japan) has been stuck in a locked state
since 2026-09-26 JST. I would like to ask for it to be unlocked.

Subscription ID: 901ad8fe-1706-4dd5-8360-c4df7dec87da
Environment: Production, JP

What we did

  1. The subscription was on a ¥550/month STATIC plan variation.

  2. To offer a paid add-on, we called SwapPlan to move it to a ¥660/month
    variation. This created a scheduled SWAP_PLAN action.

  3. When the customer removed the add-on within the same billing period, our
    code called DeleteSubscriptionAction on that SWAP_PLAN action.

  4. Since then, every SwapPlan call on this subscription returns:

    INTERNAL_SERVER_ERROR
    “Subscription ID 901ad8fe-1706-4dd5-8360-c4df7dec87da is locked and is
    not billable. Please retry or contact support.”

We have since removed SwapPlan and DeleteSubscriptionAction from our code
entirely — the add-on is now a separate subscription created through a
payment link — so nothing in our system touches this subscription any more.
The lock has not cleared on its own after more than 24 hours.

Current state

  • RetrieveSubscription returns status ACTIVE, with a card on file.
  • Our logging only enumerated SWAP_PLAN actions and showed none remaining.
    We have not verified whether a CHANGE_BILLING_ANCHOR_DATE action is still
    attached, so I cannot rule that out.

Requests

  1. Could you unlock subscription 901ad8fe-1706-4dd5-8360-c4df7dec87da?

  2. While it is in this state, will the next scheduled billing (2026-10-18)
    succeed? The wording “not billable” is our main concern, since this is a
    live paying customer.

  3. Separately: SearchSubscriptions returns HTTP 500 for the entire request
    when this locked subscription is included in the result set (we filter by
    customer_ids). Is that expected behaviour? It silently breaks subscription
    syncing for this merchant, and we only noticed because we added error
    logging. If it is not expected, I am happy to open a separate topic.

Thank you.

Thanks for the detailed report, and sorry for the trouble on a live subscription.

I’ve escalated this to the Subscriptions team to clear the lock on 901ad8fe-1706-4dd5-8360-c4df7dec87da, and I’ve also flagged your question about the 2026-10-18 billing cycle and the SearchSubscriptions 500. I’ll update here as soon as I hear back.

In the meantime, please don’t retry SwapPlan or DeleteSubscriptionAction on this subscription, as that may complicate the repair.

One thing that would help us confirm the cause: could you check whether your code deleted all actions returned by RetrieveSubscription, rather than only the SWAP_PLAN one? Deleting a CHANGE_BILLING_ANCHOR_DATE action is not supported, and a SwapPlan call can generate one automatically alongside the swap.

The subscription has been unlocked and is back in a normal state. You should be able to make changes to it again.

On your questions:

Billing on 2026-10-18: Now that the lock is cleared, the cycle should bill as scheduled. Do keep an eye on it and let us know if anything looks off.

What caused it: The original SWAP_PLAN deletion was undone successfully — a later request is what triggered the lock. Unfortunately the logs from that window have aged out, so we can’t pinpoint the exact call.

One thing worth checking on your side: deleting a CHANGE_BILLING_ANCHOR_DATE action is not supported, and a SwapPlan call can generate one automatically alongside the swap. If your code deleted every action returned by RetrieveSubscription rather than just the SWAP_PLAN one, that’s the most likely culprit. Target only the specific supported action types (PAUSE, RESUME, CANCEL, SWAP_PLAN) — and if an unwanted billing-anchor action remains, contact us rather than deleting it.

SearchSubscriptions returning 500: This is expected behaviour today. The team may improve it in future, but there’s no committed timeline. For now, if you need to defensively handle it, narrowing the result set to exclude an affected subscription is the practical workaround.