Subscription Payment Link checkout fails in Japan before Payment or Subscription is created

Questions
,
1

Hello,

I am implementing a monthly subscription using the Square Checkout API in Production in Japan.

The Payment Link is created successfully with HTTP 200. However, when the buyer enters the required information on the Square-hosted Checkout page and attempts to complete the order, Checkout displays an error indicating that the order could not be completed and asks the buyer to try again.

No Payment or Subscription appears to be created.

Environment: Production / Japan

Subscription Plan ID:
JIQLQY56RKRND52WLH5EJE77

Subscription Plan Variation ID:
TLWPXNB7ROWLRLPORVVUHIJS

Variation configuration:

  • pricing.type: STATIC
  • cadence: MONTHLY
  • price: 1480 JPY
  • one phase

Affected Order ID:
pJYHLxQICZ8wT08AddyKI7zGeA9YY

Payment Link ID:
WONFBLWXMZX34644

POST /v2/online-checkout/payment-links returns HTTP 200.

The Payment Link uses the Variation ID above as checkout_options.subscription_plan_id, and quick_pay.price_money is 1480 JPY.

After the hosted Checkout failure, I retrieved the Order using GET /v2/orders/{order_id}.

The Order remains:

  • state: DRAFT
  • version: 1
  • fulfillment.state: PROPOSED
  • total_money: 1480 JPY
  • net_amount_due_money: 1480 JPY
  • no tenders
  • no customer_id

The Order’s updated_at is also unchanged from when the Payment Link was originally created.

Therefore, it appears that the hosted Checkout flow stops before the Order is updated and before a Payment or Subscription is created.

I previously tested a RELATIVE pricing Subscription Plan Variation and experienced the same Checkout error. I then created the STATIC variation described above, but the behavior did not change.

Could you please help determine:

  1. Whether this Subscription Checkout configuration is supported for Japanese Square accounts.
  2. Whether any additional account, location, capability, or approval is required in Japan.
  3. What could cause hosted Checkout to stop before customer/card/payment/subscription creation.
  4. Whether 3D Secure or another Japan-specific payment requirement could cause this behavior.
  5. Whether Square staff can inspect server-side Checkout logs associated with the Order ID above.

I can provide additional non-sensitive request/response details if needed.

Thank you.

3

@jvp-rider-lab Could you please provide your application ID and any timestamps and timezone associated with the failed attempts?

4

Thank you for your response.

My Production Application ID is:
sq0idp-dpORJC7mnrPRQbaVjDaV9g

One of the failed attempts occurred shortly after the Payment Link was created at:
September 24, 2026, 02:48:31 JST (UTC+9)

The corresponding Payment Link ID is:
WONFBLWXMZX34644

The corresponding Order ID is:
pJYHLxQICZ8wT08AddyKI7zGeA9YY

Please note that 02:48:31 JST is the Payment Link creation timestamp. The hosted Checkout failure occurred shortly afterward, so I do not have the exact second of the Checkout failure.

The environment was Production.

Please let me know if you need any additional identifiers or timestamps to locate the failed Checkout attempt.

Thank you.

5

@jvp-rider-lab - thank you for providing those details. I can see that you successfully created the payment link, but I cannot find any records of a payment attempt against that payment link.

Can you please test against the returned payment link for the given Order ID and report if you see the same error?

Payments for a RELATIVE priced Subscription Plan Variation is not supported via payment links, and the correct workaround is to use a STATIC variation type.