DeleteSubscriptionAction returns HTTP 500, and an unexpected charge occurred after deleting a SWAP_PLAN action

Hello,

We are a Japanese nonprofit organization using the Subscriptions API in production. We are experiencing two issues that appear to be related and would appreciate your help investigating them.

Target

Location ID     : KXE2FFP9ZMN74
Subscription ID : 2159b95f-de33-4566-bb73-06c99d735c9b
Customer ID     : [redacted]
Environment     : Production
Square-Version  : 2026-07-15

Issue 1: An unexpected charge occurred

On 2026-08-30 at 00:39:48 JST (2026-08-29 15:39:48 UTC), we called DeleteSubscriptionAction to remove a scheduled SWAP_PLAN action:

action_id      : f0a1dfdc-675b-3a14-a640-99f7ac1cee83
effective_date : 2026-09-09

The request succeeded.

Three seconds later, at 00:39:51 JST (15:39:51 UTC), an invoice that we did not request was automatically issued and immediately charged:

Amount   : ¥1,500 (one full month of the plan)
Due date : 2026-08-30
Line item: Claude NPOプラン(スタンダードシート)

As a result, charged_through_date advanced from 2026-09-09 to 2026-10-09.

We expected the next billing date to be 2026-09-09 and did not expect any charge to occur on 2026-08-30, 10 days before that date.

We have already refunded this charge through the Square Dashboard.

Questions

  • Why was this invoice issued, and which billing period did it cover?
  • Is it expected behavior for deleting a SWAP_PLAN action to trigger a recalculation of the billing schedule and an immediate charge?
  • We checked /v2/subscriptions/{id}/events and found no event corresponding to this charge. Only two events are present: START_SUBSCRIPTION and BILLING_ANCHOR_DATE_CHANGED, both dated 2026-08-15. Is it expected for a charge to occur without a corresponding subscription event?

Issue 2: DeleteSubscriptionAction returns HTTP 500

Two actions currently remain on this subscription:

CHANGE_BILLING_ANCHOR_DATE
  action_id      : bfb42563-4676-43b5-93fc-0927b1f1328d
  effective_date : 2026-09-09

CANCEL
  action_id      : 10aec353-53f9-3409-aa71-c38654c3d402
  effective_date : 2026-10-09

Attempts to delete them returned:

Deleting CHANGE_BILLING_ANCHOR_DATE → HTTP 500 INTERNAL_SERVER_ERROR
Deleting CANCEL                     → HTTP 409 CONFLICT

After both attempts, the subscription’s version, charged_through_date, and action list remained unchanged, and no additional charge occurred.

Questions

  • Could you investigate why deleting CHANGE_BILLING_ANCHOR_DATE returns HTTP 500? Since the API returns a 5xx rather than a 4xx response, this appears to indicate a server-side error rather than an invalid request.
  • Is there any way to remove this action, either through the API or the Square Dashboard?
  • Could the HTTP 409 response when deleting the CANCEL action be related to the remaining CHANGE_BILLING_ANCHOR_DATE action?

About the CHANGE_BILLING_ANCHOR_DATE action

We have never called the ChangeBillingAnchorDate endpoint.

On 2026-08-16 at 12:42 JST, we called SwapPlan with only the following request body:

{
  "new_plan_variation_id": "YCQFYUTI4RF2MDFIU22RSE6N"
}

The response contained two actions: SWAP_PLAN and CHANGE_BILLING_ANCHOR_DATE.

We therefore believe that the CHANGE_BILLING_ANCHOR_DATE action was generated automatically by Square.

Please also note that the BILLING_ANCHOR_DATE_CHANGED event in the subscription event history is dated 2026-08-15, the subscription start date, rather than 2026-08-16 when SwapPlan was called.

Questions

  • Is it expected for SwapPlan to automatically create a CHANGE_BILLING_ANCHOR_DATE action?
  • The billing anchor date had already been set to the 9th when the subscription was created on 2026-08-15. It appears that another anchor-date-change action setting it to the same value was created. Could this duplicate action be related to the inconsistent state we are seeing?

Timeline

2026-08-15 20:35 JST  Subscription created via Checkout
                      (prorated charge of ¥1,210)

2026-08-16 12:31 JST  UpdateSubscription used to clear canceled_date
                      (cancellation rescinded)
                      Verified afterwards:
                      canceled_date unset, actions empty

2026-08-16 12:42 JST  SwapPlan called (Standard → Premium)
                      Response contained:
                      SWAP_PLAN and CHANGE_BILLING_ANCHOR_DATE

2026-08-30 00:39:48 JST
                      DeleteSubscriptionAction called for SWAP_PLAN
                      Request succeeded

2026-08-30 00:39:51 JST
                      Unexpected invoice issued and charged (¥1,500)

2026-08-30 00:40 JST  Cancellation requested
                      CANCEL action created

2026-08-30 00:49 JST  Charge refunded through Square Dashboard

2026-08-30 01:0x JST  Attempted to delete the remaining actions
                      → HTTP 500 / HTTP 409

What we would like

  1. An explanation of why the unexpected charge in Issue 1 occurred
  2. Removal or repair of the CHANGE_BILLING_ANCHOR_DATE action (bfb42563-4676-43b5-93fc-0927b1f1328d)
  3. Guidance on any operations or API sequences we should avoid to prevent this issue from recurring

Context

We are currently migrating our members to recurring billing through the Subscriptions API.

This incident occurred during what we believe should be a routine operation: cancelling a scheduled plan change. Because the same unexpected charge could potentially occur for other subscriptions, we have temporarily disabled our plan-change feature until we understand the cause.

We would appreciate your help investigating this issue and any guidance on how to safely handle scheduled plan changes in the meantime.

We can provide full request and response logs, including timestamps and request details, if needed. Sensitive credentials and access tokens will be redacted.

Thank you.

Hi @szsuke - thank you for flagging. I’ve escalated this issue with the team internally and will revert shortly.

@szsuke - Thanks for your patience while we investigated this.

We confirmed that the behavior you reported was caused by an issue in Square’s subscription processing. When the scheduled plan change was removed, a related billing-anchor action remained and caused the subscription’s billing schedule to be recalculated. This incorrectly generated and charged the invoice for the September 9 - October 9 billing period earlier than intended.

We also confirmed that the HTTP 500 you received while deleting the remaining billing-anchor action left the subscription temporarily locked, which caused the subsequent conflict when you tried to remove the cancellation.

We have now manually corrected the affected subscription by removing the stale billing-anchor action and clearing the lock. Our engineering team has identified the underlying causes and is working on permanent fixes. Until we confirm that those fixes are deployed, we recommend continuing to avoid deleting scheduled plan-change actions using this sequence until a fix has been released.

Hi @jseok, we have just encountered an apparently related failure on one owner-only GBP 1 production test subscription (13 September 2026, approximately 17:14 UTC).

Our sequence was a scheduled PAUSE with a dated RESUME, not a plan swap. Square also created a related CHANGE_BILLING_ANCHOR_DATE action. Deleting the exact RESUME action succeeded and was verified with a fresh read. The next deletion, for the related billing-anchor action, returned INTERNAL_SERVER_ERROR. We stopped immediately and have not retried it or sent a new billing-day request.

Fresh readback still shows ACTIVE, GBP 1, the original billing day, PAUSE on 7 October and CHANGE_BILLING_ANCHOR_DATE on 14 October. The latest invoice read shows only the existing paid invoice, with no new invoice observed.

Has the fix mentioned above been deployed? Could you investigate and advise on repair of this test subscription, including any lock? Please provide a private route for the subscription and request IDs. We are keeping this disabled for other customers and are not publishing customer details or credentials here. Thank you.

@james-hill Thanks for reporting - I’ll check on this internally and get back to you.

Thanks so much, I look forward to your response. It would be incredibly helpful for our customers if we could be flexible on changing their subscription monthly billing dates

@james-hill - can you send me a DM with the subscription_id of the affected subscription? I will update here when I hear back from the team.

Thanks for your patience - here are some details from our team.

  • The fix that was released was to address the original issue of erroneous invoice generation as a result of deleting the SWAP_PLAN action.
  • Direct deletion of a CHANGE_BILLING_ANCHOR_DATE action is not a supported action.
  • If you need to adjust a subscription action, make sure to target the specific supported action rather than attempt to delete every returned action. If an unwanted billing-anchor action remains, the recommendation is to contact support for review rather than delete it, or issue another billing-day change as a workaround.

@james-hill - once you DM me with the subscription_id, I can make sure the team unlocks it for you!

Thanks @jseok. Your profile is hidden and I cannot see a Message option. Could you start a private conversation so I can send the owner-test subscription ID for the unlock? We have blocked deletion of billing-anchor actions and have not retried the failed operation.

I also tested your suggested second billing-day request in Sandbox today. The current billing day changed to 16, but the existing scheduled change to day 19 remained in include=actions. Does that old action still execute, or should your team remove it? I can share the synthetic test IDs and responses privately.

@james-hill - The existing billing-day request will still execute. The workaround would be to schedule the proper billing-day request to execute right after the existing billing-day request.

I do want to note that this action may have invoicing implications, but if you’ve configured proration for your subscriptions then it should be fine.

Hi @jseok ,

Thank you very much for the detailed explanation and for taking the time to investigate this issue with your team.

The clarification about the fix and the handling of CHANGE_BILLING_ANCHOR_DATE actions is very helpful. We’ll update our implementation accordingly.

We really appreciate your support and all the work your team put into resolving this.

Thank you again!