# Sandbox: subscriptions become DEACTIVATED on the billing date without creating an Order or Invoice (JP/JPY) **URL:** \ **Category:** Questions\ **Created:** [September 23, 2026, 9:20pm UTC](https://developer.squareup.com/forums/t/sandbox-subscriptions-become-deactivated-on-the-billing-date-without-creating-an-order-or-invoice-jp-jpy/27959 "2026-09-23T21:20:34Z")\ **Posts on this page:** 3\ **Page:** 1
**Author:** ![Din](https://avatars.discourse-cdn.com/v4/letter/d/ccd318/32.png) [@Din](https://developer.squareup.com/forums/u/Din)\ **Post date:** [September 23, 2026, 9:20pm UTC](https://developer.squareup.com/forums/t/sandbox-subscriptions-become-deactivated-on-the-billing-date-without-creating-an-order-or-invoice-jp-jpy/27959/1 "2026-09-23T21:20:34Z")
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 ## 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 - A brand new plan, customer and card — same result. - Three independent Japan Sandbox test accounts, different merchants — - 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 - One-off CreatePayment in the same Sandbox returns COMPLETED with a - automatic\_payment\_source is rejected on CreateSubscription at this API ## 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. ---
**Author:** ![tony120starkk](https://avatars.discourse-cdn.com/v4/letter/t/77aa72/32.png) [@tony120starkk](https://developer.squareup.com/forums/u/tony120starkk)\ **Post date:** [September 24, 2026, 11:48am UTC](https://developer.squareup.com/forums/t/sandbox-subscriptions-become-deactivated-on-the-billing-date-without-creating-an-order-or-invoice-jp-jpy/27959/3 "2026-09-24T11:48:34Z")
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! ---
**Author:** ![jseok](https://avatars.discourse-cdn.com/v4/letter/j/f475e1/32.png) [@jseok](https://developer.squareup.com/forums/u/jseok)\ **Post date:** [September 29, 2026, 6:30pm UTC](https://developer.squareup.com/forums/t/sandbox-subscriptions-become-deactivated-on-the-billing-date-without-creating-an-order-or-invoice-jp-jpy/27959/4 "2026-09-29T18:30:42Z")
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_SUBSCRIPTION`reason 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.