Web Payments SDK — ACH RECURRING_CHARGE always returns UnexpectedError (sandbox)

Questions
1

We’re adding recurring ACH (bank on file) with the Web Payments SDK in sandbox. Every RECURRING_CHARGE tokenization fails with UnexpectedError (“An unexpected error occurred while authorizing the payment.”). event.detail.error is:

{"errors":[],"name":"UnexpectedError"}

Setup: sandbox, Web Payments SDK 1.85.0 (sandbox CDN), location LHHQFTBYJC0X0.

  • STORE works: ach.tokenize({ intent: 'STORE', accountHolderName }) through Plaid (First Platypus Bank, user_good) → CreateBankAccount → bact:2GVUNXJzbzCKWtRv3GB, status VERIFIED, debitable, on customer 2EB22S8MD76ATQBACSFJ1Q1J88.
  • A one-off ach.tokenize({ intent: 'CHARGE', bankAccountId, amount, currency }) on the same account proceeds normally.
  • Every RECURRING_CHARGE fails identically:
// variable amount
{ intent: 'RECURRING_CHARGE', bankAccountId, startDate: '2026-10-01',
  frequency: { monthly: { days: { daysOfMonth: [1] } } }, variableAmount: true }
// fixed amount: same result
{ ..., amount: '869.53', currency: 'USD' }
// daily, as in the docs: same result
{ ..., frequency: { days: 30 } }

Weekly frequency, and a startDate of today or tomorrow, fail the same way.

  • The Application ID and access token belong to the same application. The sandbox personal access token (regenerated today) has BANK_ACCOUNTS_READ but not BANK_ACCOUNTS_WRITE, which the bank-on-file guide lists as required.

Questions

  1. Is RECURRING_CHARGE available in sandbox, and does it need enabling for our application or seller account?
  2. Does it require BANK_ACCOUNTS_WRITE, and if so, how do we obtain it? Personal access tokens don’t include it; is OAuth required?
  3. Is anything else required that isn’t in the docs?
3

Welcome to the Developer Forum!

We’d have to whitelist your app id for RECURRING_CHARGE. Would you please provide the application id so that I can go ahead and enable it for you?

4

Thanks, jaeha! Here are both of our application IDs:

  • Sandbox: sandbox-sq0idb-u9MeKF6V5tUsHHd86DwDMg
  • Production: sq0idp-IzhluGWksWAMCsQgeMVRZw
    We’re using the Web Payments SDK ACH form with intent: "RECURRING_CHARGE" and variableAmount: true, for monthly tuition autopay by bank transfer. Could you enable it on both, so we can test in sandbox and then go live? Also, is there anything else the production account needs for ACH recurring charges, beyond finishing payment activation?
5

Happy to help here.

I just enabled both prod and sandbox for ‘fixed recurring auth’ so you should be able to test it with RECURRING_CHARGE with no issues. ‘variable recurring auth’ would require additional risk review before I can enable it. Would you really need this or would ‘fixed recurring auth’ suffice for you?

6

Thanks, jaeha, that’s great! Fixed recurring auth will work for us for launch, so please leave that enabled. Could you tell me what the risk review for variable recurring auth involves, and how long it usually takes? We may ask for it later, for tuition that changes month to month. I would like to proceed with enabling variable recurring auth.

7

We are currently reviewing the onboarding process for both fixed recurring and variable recurring. As of now, we are testing the variable recurring only with a select few and we will let you know if this becomes more public.