Sandbox subscription billing-period dates and unknown creation outcome

Questions
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.