Sandbox subscription billing-period dates and unknown creation outcome

Questions
1

We are validating fixed-price monthly Square Sandbox subscriptions with API2026-09-16. The subscription and dedicated owning location use America/New_York. The first STATIC phase bills the original monthly price plus a once-only activation amount; subsequent phases contain only the recurring price.

Our retained original request/claim and authenticated repeated subscription/invoice/order/payment reads show an October19 start and monthly anchor19. The captured initial invoice was created/paid on October20UTC, which was still October19 in Eastern. The subscription reports charged-through November19 and a cancellation effective November20. There is no independently corroborated service-period field or event explaining the extra day. A dedicated Eastern location did not remove the discrepancy.

The current Subscription documentation describes charged-through as the last day of an invoiced billing period. A calendar monthly term beginning October19 would ordinarily have its next exclusive boundary November19 and its final invoiced-through day November18. We are holding access/renewal/proration attribution rather than guessing a date adjustment or treating invoicing as proof of payment. The initial Sandbox payment in the completed cancellation fixture has been fully refunded through its original one-shot request; it will not be recreated or replayed.

Questions:

  1. Which authoritative subscription/invoice fields establish the actual paid service-period boundaries and next billing day for this case, in the subscription’s timezone?
  2. Why do start/anchor19, charged-through November19 and stop November20 disagree with that calendar-month interpretation? Is this Sandbox behavior, processing timezone, documented billing semantics or a defect?
  3. What supported Sandbox procedure can validate the exact initial period and future monthly/annual renewal without production charges or invented clock/date offsets?
  4. A separate original creation produced no usable response candidate. Repeated complete original-customer invoice discovery and read-only customer/location/source subscription search return none. Can Square establish the original request’s outcome from its immutable request key/logs, without replaying creation or resetting that key?

Specific Sandbox identifiers and original redacted timestamps can be supplied through an approved private support channel. No credentials, card nonce, authentication headers, private key or real customer information should be sent.

3

Adding redacted request/response excerpts and a later, separate Sandbox observation to make this easier to diagnose. No credentials, real customer data, card nonce, or actual Sandbox identifiers are included.

Environment and sequence

  • https://connect.squareupsandbox.com, Square-Version: 2026-09-16.
  • Dedicated US Sandbox location and subscription both use America/New_York.
  • Fixed-price variation: first MONTHLY STATIC phase = USD 45.00 for one period (20.00 recurring + 25.00 once-only activation); subsequent MONTHLY STATIC phase = USD 20.00, with no finite period count. No price override or trial.
  • Created on October 20 at 05:32:41 Eastern / 09:32:41 UTC, avoiding the earlier UTC/Eastern date crossover.
  • One creation request, then one immediate cancellation request to prevent future test renewal; later observations were GET-only. That cancellation timing may be relevant, so I am including it explicitly.

Redacted creation body (POST /v2/subscriptions):

{
  "idempotency_key": "ORIGINAL_KEY_REDACTED",
  "location_id": "LOCATION_REDACTED",
  "plan_variation_id": "TWO_PHASE_VARIATION_REDACTED",
  "customer_id": "CUSTOMER_REDACTED",
  "card_id": "CARD_REDACTED",
  "timezone": "America/New_York",
  "source": { "name": "CORRELATION_LABEL_REDACTED" }
}

start_date and monthly_billing_anchor_date were intentionally omitted in this later test. We did not manually advance a clock or insert a one-day offset.

GET immediately after creation, before cancellation (selected fields):

{
  "start_date": "2026-10-20",
  "status": "ACTIVE",
  "created_at": "2026-10-20T05:32:41-04:00",
  "timezone": "America/New_York"
}

Then POST /v2/subscriptions/SUBSCRIPTION_REDACTED/cancel, with no request body, at 09:32:43 UTC. The subsequent GET at 09:32:45 UTC returned these selected fields:

{
  "start_date": "2026-10-20",
  "monthly_billing_anchor_date": 20,
  "charged_through_date": "2026-11-20",
  "canceled_date": "2026-11-20",
  "billing_end_date": "2026-11-20",
  "status": "ACTIVE",
  "created_at": "2026-10-20T05:32:41-04:00",
  "timezone": "America/New_York"
}

Repeated GETs through 09:34:51 UTC retained those dates. The returned start event was:

{
  "subscription_event_type": "START_SUBSCRIPTION",
  "effective_date": "2026-10-20"
}

The linked invoice was PAID, created at 2026-10-20T09:32:44Z, with timezone America/New_York. Its linked payment was COMPLETED for $45.00 USD (amount_money.amount = 4500, currency = USD). The selected invoice/payment reads did not provide an independent service-period start/end that resolved the date question. This is fake Sandbox money, not production.

Separate observation from the original October 19 fixture: its complete later event read reported START_SUBSCRIPTION.effective_date = 2026-10-20, while the subscription still reported start_date = 2026-10-19, anchor 19, charged-through November 19, and cancellation November 20. We have not assumed that event alone proves a paid period or that these two fixtures have the same underlying cause.

Could Square clarify:

  1. Is charged_through_date inclusive or exclusive in this scenario, especially after an immediate cancellation? If cancellation is effective November 20, does access end at the start of that day or after it?
  2. Does cancelling immediately after creation, before the initial invoice has finished processing, affect these dates? Do the two STATIC phases affect the first period or cancellation boundary?
  3. Which supported API field(s) establish the exact exclusive paid-period boundary and next renewal date for access and proration? We are keeping our interpretation blocked rather than subtracting an undocumented day.
  4. For the original fixture, how should we reconcile the different subscription start date and delayed start-event effective date? Is the related Sandbox start-date fix discussed in Sandbox subscription returns November 3 for requested November 2 start relevant and deployed?

The unrelated unknown-creation request from the original question remains unreplayed with its original key preserved. If private Sandbox identifiers or Developer Console request logs are needed for either case, please specify the private support channel and which requests to supply. We will not post tokens, nonces, or private identifiers publicly or reproduce this with real payments.

4

Before recommending any date adjustments or retrying the creation request, we need to correlate the behavior with the original Sandbox requests.

Could you share the following through the DM I just sent you?

  • Your Sandbox application ID and affected location/subscription IDs.
  • The timestamp and time zone, request body, and response for the relevant subscription creation and cancellation calls, plus the subsequent subscription read showing the dates in question. Include request IDs if available.
  • For the creation attempt with an unknown outcome, the original idempotency key, timestamp/time zone, and any response or error captured in your API logs.

These details will help us investigate the date discrepancy and determine what happened to the original creation attempt.