I’m building a system that needs to process recurring ACH payments. The client bills customers based on usage, so the amounts will vary from month to month. I’m using the Square Web Payments SDK to capture the authorization and generate a bnon token. I then send the bnon to my backend and create a bank account id (bact) token for it using the create_bank_account API. The bact is sent back to the front end to be converted to a bauth, using the Web Payments SDK, ach.tokenize function, using the parameters outlined here: Store and Charge Bank Accounts on File
The call to the ach.tokenize function fails every time, with Square’s server returning a 500 error. When I inspect the network call, I can see that the field frequency.monthly.days.daysOfMonth is being sent as an empty array, , despite hardcoding it as [1] in my application. This is the only thing that looks like it could be causing the issue.
Are there any other reasons the backend would throw a generic 500 error?
Update: I have made progress on the payload structure, but the 500 error persists.
I discovered that when using the frequency object as documented, the SDK sends days_of_month as an empty array. However, if I replace frequency with cadence: ‘MONTHLY’, the SDK correctly populates the days_of_month array in the network request based on the startDate.
Despite the payload now appearing correctly formatted in the network tab, the call to /debit-auth/create still returns a 500 Internal Server Error (Unexpected Error).
Current Status:
Stage 1: Completed Plaid authorization and received bnon token. Converted bnon to bact via backend call to bank_accounts.create_bank_account API successfully.
Stage 2: Calling ach.tokenize with the bankAccountId: bactID, intent: ‘RECURRING_CHARGE’, variableAmount: true, startDate: ‘2026-04-01’ and cadence: ‘MONTHLY’.
Bank Account Status: Verified (Sandbox).
The Issue: The server-side response is a generic 500 with no descriptive error body.
Since the payload syntax now matches what the SDK expects, are there specific Sandbox account configurations or startDate constraints that trigger a 500 on the ach.tokenize call for recurring charges?
Is there someone from Square who can weigh in on this? We’ve implemented this exactly as instructed in the official documentation, but are getting a generic 500 error with no other information to help troubleshoot.