Sandbox: subscriptions become DEACTIVATED on the billing date without creating an Order or Invoice (JP/JPY)

Questions
1

Hi — I’m hitting a wall verifying Subscriptions before going to production, and I’d

like to know whether what I’m seeing is an expected Sandbox limitation.

## Setup

Sandbox, Japan seller account, JP / JPY location, Square-Version 2026-08-19.

A SUBSCRIPTION_PLAN with one SUBSCRIPTION_PLAN_VARIATION, MONTHLY cadence,

STATIC pricing of 3000 JPY.

## What happens

Every subscription I create becomes DEACTIVATED on (or within seconds of) its

billing start date. Nothing is billed and nothing is produced:

  • invoice_ids stays empty

  • charged_through_date is never set

  • no Order is created

  • ListSubscriptionEvents returns only START_SUBSCRIPTION followed by

    DEACTIVATE_SUBSCRIPTION, and the `info` field is null, so there is no

    reason given

## What I have already ruled out

  • Card on file, and no card at all — same result either way.

  • STATIC pricing, and RELATIVE pricing with an order_template_id passed in

    the CreateSubscription `phases` array — same result.

  • A brand new plan, customer and card — same result.

  • Three independent Japan Sandbox test accounts, different merchants —

    same result in all three.

  • The location is ACTIVE with CREDIT_CARD_PROCESSING and AUTOMATIC_TRANSFERS.

  • The Invoices API itself works fine in the same Sandbox: I built an Order

    manually, created an Invoice from it and published it successfully

    (status UNPAID, invoice number issued, public URL returned).

  • One-off CreatePayment in the same Sandbox returns COMPLETED with a

    receipt_url, so the card and the location are usable.

  • automatic_payment_source is rejected on CreateSubscription at this API

    version (“The field named ‘automatic_payment_source’ is unrecognized”),

    so I cannot explicitly request invoice-based billing instead of card.

## Questions

1. Is subscription recurring billing simply not exercised in Sandbox? If so,

is that documented somewhere I can point my client to?

2. If it is supposed to run, what am I missing that causes the immediate

DEACTIVATE_SUBSCRIPTION with no reason?

3. Is there any supported way to inspect what a subscription invoice will

contain — line items, applied tax rate, tax amount per rate — before

going to production? This is for Japanese qualified-invoice (適格請求書)

compliance, so I need to confirm the tax breakdown appears on the invoice

before we bill real customers.

Subscription IDs, all Sandbox:

d4baaaa1-f61e-47b9-a2b4-673603559ca3 (third account, card on file)

b716493c-b3cc-4f51-be09-63b30c116b89 (no card)

ef0a134f-574d-444e-b5c0-39d397c0b168 (card on file)

Happy to share full request/response bodies if that helps. Thanks.

3

This is an expected Sandbox quirk—Square’s recurring billing engine does not auto-process Sandbox subscriptions. Test payment flows manually via the Invoices API to verify Japanese tax breakdowns beforehand!

4

Thanks for the detailed testing. Based on what you’ve shared, this appears consistent with a Sandbox limitation rather than an issue with your subscription configuration.

Sandbox can be used to validate Subscriptions API request/response shapes and some subscription object behavior, but it does not reliably exercise the full end-to-end subscription lifecycle. In particular, recurring billing and the generated invoice/order flow are areas where Sandbox can differ from production. Seeing the subscription start and then deactivate without an invoice, order, charged_through_date, or DEACTIVATE_SUBSCRIPTIONreason is consistent with that Sandbox parity gap.

For production behavior, subscriptions should generate invoices/orders according to the billing cadence. If you need to validate the full billing lifecycle, we recommend doing so in production with a controlled low-value test.

For the Japan qualified-invoice/tax validation specifically, the best Sandbox workaround is to create the Order you expect the subscription to generate directly in Sandbox, using the same line items, taxes, discounts, and amounts, then create/publish an Invoice from that Order with the Invoices API. That lets you inspect the Order tax breakdown and invoice output without relying on the subscription billing run.

There isn’t currently a separate endpoint to preview a subscription-generated invoice before the billing run creates it.