Sandbox bank-on-file one-time ACH succeeds, but RECURRING_CHARGE returns UnexpectedError

We are implementing fixed monthly ACH installment payments using Square’s Web Payments SDK and Bank Accounts API. Can you confirm whether recurring bank-on-file authorization is enabled and working for this Sandbox application, and identify the cause of the authorization error?

  • Application: Oasis Technologies Invoicing
  • Sandbox application ID: sandbox-sq0idb-j1KBTxpbKvqsktA8rlxKEg
  • Sandbox location: L4R1YHJMYCWGS
  • Test date: September 24, 2026
  • SDK: https://sandbox.web.squarecdn.com/v1/square.js
  • API version for backend calls: 2026-09-16
  • Browser: Chrome; isolated localhost test harness with no third-party application framework

We completed Plaid linking, received a genuine BNON token from intent STORE, and successfully called CreateBankAccount. Square returned a VERIFIED, debitable US checking account associated with a synthetic customer.

Using this stored bank with intent CHARGE displayed Square’s authorization confirmation, returned a BAUTH token, and successfully submitted a $1.00 sandbox ACH payment. Its initial status was PENDING. Payment ID: dyg11xlbPxhDdirPt8G3MldZECYZY, created at 2026-09-24T06:40:59.981Z. Repeating the identical CreatePayment idempotency key returned the same payment ID.

However, the documented recurring configuration fails before providing a reusable BAUTH:

const payments = Square.payments(sandboxApplicationId, sandboxLocationId);
const ach = await payments.ach({
  transactionId: crypto.randomUUID(),
  redirectURI: location.origin + '/',
});
await ach.tokenize({
  intent: 'RECURRING_CHARGE',
  bankAccountId: verifiedCustomerBankId,
  amount: '1.00',
  currency: 'USD',
  frequency: {
    monthly: {
      occurrence: 1,
      days: { daysOfMonth: [24], endOfMonth: false },
    },
  },
  startDate: '2026-09-24',
});

The SDK reports:

UnexpectedError
An unexpected error occurred while authorizing the payment.

The same error occurred when testing a monthly schedule starting October 24 with an off-cadence first installment on September 24, and when using the simpler documented { days: 30 } recurring frequency as a diagnostic control. The daily-frequency variant is only a diagnostic; our requested production behavior is calendar-month billing.

The token status response does not list BANK_ACCOUNTS_WRITE, although the actual CreateBankAccount request succeeded. Is this expected for the current beta, or is recurring authorization subject to additional application/account enablement? Please do not rotate or modify our production credentials or existing subscriptions; an unrelated existing client plan must remain unchanged.

The symptom resembles the unresolved reports here:

Documentation followed:

Please provide a working sandbox configuration or identify any required account enablement before we activate this feature for clients. Square Dashboard support directed us to the Developer Forums today.

Welcome to the Developer Forum!

Thanks for reaching out with the detailed context. RECURRING_CHARGE works only after we manually add you to our whitelist. I just enabled your access, so it should be running without any issues. Please test it again and let me know if the issue persists.

Thank you, @jaeha. Recurring authorization now works in Sandbox after the enablement and a monthly-options correction.

Fresh tests on September 26, 2026 at approximately 01:30–01:32 UTC (September 25 EDT), using the same sandbox app/location and SDK 1.85.0:

  • Monthly $1.00 starting September 25: Square displayed ‘Every month on the 25th,’ returned BAUTH, and CreatePayment accepted the first ACH debit as PENDING. Payment ID: 9AbFcWeolAXpp5TNKTet2ZQRXeWZY.
  • $1.03 immediately on September 25, then $1.00 monthly starting October 25 using offCadencePayments: Square displayed both amounts/dates correctly, returned BAUTH, and accepted the $1.03 debit as PENDING. Payment ID: pwYvL9zRPwAwWNrlcVyudEuPncKZY.
  • Retrying each identical CreatePayment idempotency key returned the same payment ID. These are synthetic Sandbox payments; no real money moved.

One SDK detail: our original days: { daysOfMonth: [25], endOfMonth: false } still produced UnexpectedError after enablement. Changing only that object to days: { daysOfMonth: [25] } resolved it. This matches the property-presence issue reported in topic 27996 and may warrant an SDK/documentation fix.

Before activating live financing, could you confirm whether this access also covers recurring bank-on-file authorization and charges for our corresponding production application/merchant, or whether production needs separate enablement? Please preserve our existing production credentials, invoices and subscriptions. We understand that our application must schedule the finite monthly CreatePayment calls; the authorization itself does not schedule withdrawals.

Thank you for enabling RECURRING_CHARGE for our sandbox application. We retested today and can successfully obtain a bauth token for a basic monthly authorization.

We found a separate authorization failure while implementing a deposit followed by fixed monthly installments. With the same sandbox application and verified synthetic bank account:

  • Regular monthly authorization succeeds.
  • Monthly end-of-month authorization without off-cadence payments succeeds.
  • Monthly end-of-month authorization with only the future first installment as an off-cadence payment succeeds.
  • Monthly end-of-month authorization with only today’s deposit as an off-cadence payment succeeds.
  • Combining today’s deposit and the future first installment in offCadencePayments fails before authorization completes. Both our 12-month and 24-month quote variants fail.

One failing example authorizes a $5.30 deposit on 2026-10-01, an $8.41 first installment on 2026-10-31, and monthly $8.39 installments beginning 2026-11-30. The request uses frequency.monthly.occurrence=1 and days.endOfMonth=true. The SDK returns UnexpectedError with the message “An unexpected error occurred while authorizing the payment.” It provides no error code or additional errors.

The documented offCadencePayments field is an array. Is this combined schedule supported, and is there a known issue or required request change? Our application maintains the finite accepted schedule and will submit only its authorized payments; we have made no Payments API calls in these new tests.

Could you also answer our previous question about production access: does our production application need a separate enablement for BANK_ON_FILE/RECURRING_CHARGE, and can you confirm its current eligibility? Customer financing enrollment remains disabled until the exact schedule and production support are verified.

No access tokens, authorization tokens, customer data, or bank identifiers are included in this message.