Axiom Armor: sandbox recurring ACH fails while same-bank one-time authorization succeeds

Questions
1

We are integrating a fixed ACH lease schedule for Axiom Armor: $100 down, then eighteen monthly $75 payments, with the first installment 14 days after the down payment.

In an isolated Mac Safari test on September 25, 2026, using Square sandbox Web Payments SDK 1.85.0:

- STORE completed through Plaid First Platypus Bank using the documented synthetic credentials.

- CreateBankAccount succeeded and returned VERIFIED, debitable=true.

- On that same saved bank, a one-time $100 CHARGE displayed Square’s authorization prompt and returned a successful BAUTH token.

- RECURRING_CHARGE for $75 USD, monthly on day 9 starting 2026-10-09, failed before the authorization prompt/token with UnexpectedError. The event reported {“errors”:[],“name”:“UnexpectedError”}.

- A minimal monthly frequency specifying only daysOfMonth [9], without the optional occurrence or endOfMonth fields, failed identically.

- The listener was registered before tokenization, with a fresh transaction ID. The test ran outside our Replit app.

Sandbox application ID: sandbox-sq0idb-bdwkRUNf6pa5B53drIEkmg

Sandbox location ID: L71TB8SQK189W

Backend API version: 2026-05-20

Representative failed authorization time: 2026-09-25 11:10:59 UTC

No payment was submitted. We disabled the synthetic stored bank and deleted the synthetic customer successfully after testing.

One SDK observation: the current authorization enclave treats the presence of endOfMonth as overriding daysOfMonth, even when endOfMonth is false. That explains an empty days_of_month array for that option combination, but removing the optional field did not resolve our authorization failure.

Please confirm whether fixed recurring ACH authorization is working in sandbox, whether our application requires additional enablement, and a supported working configuration. We need to distinguish an integration issue from a sandbox/service limitation before enabling automatic collections. Please do not rotate or change production credentials.

Documentation followed: Store and Charge Bank Accounts on File

This resembles the existing report: Variable recurring ACH payments

3

Follow-up test on September 25, 2026 at 15:15:28 UTC: the alternate cadence: “MONTHLY” configuration also fails with UnexpectedError with an empty errors array before the recurring authorization prompt. Options were intent RECURRING_CHARGE, amount “75.00”, currency “USD”, startDate “2026-10-09”, cadence “MONTHLY”, and the newly saved sandbox bank ID; no frequency field was supplied.

This was another isolated Mac Safari test using a fresh synthetic First Platypus bank. STORE succeeded and CreateBankAccount again returned VERIFIED and debitable=true. No payment was submitted. Cleanup confirmed bank disable HTTP 200 and customer deletion HTTP 200. The alternate configuration therefore did not resolve the recurring authorization failure.

4

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.

5

Thank you, @jaeha — the whitelist resolved the Sandbox recurring authorization failure. We have now completed a fresh in-app test with a synthetic Sandbox bank: bank storage, separate $100 one-time and $75 monthly authorizations, a $100 ACH deposit, and the first $75 ACH installment. Read-only Square API checks confirmed both payments COMPLETED with source BANK_ACCOUNT. The synthetic bank/customer were cleaned up; no real funds were charged.

Before activating live leases, could you confirm whether the access you enabled also covers recurring bank-on-file authorization and charges for our corresponding production application/merchant, or whether production requires separate whitelisting or onboarding? We are preserving our working ordinary credit-card checkout and do not want any credentials rotated or existing payment settings changed.

6

Hi @jaeha — following up because we are preparing our first live customer lease. The Sandbox recurring ACH test passed after your enablement, as reported above. Could you please explicitly confirm whether that enablement covers our corresponding PRODUCTION application and merchant for bank-on-file storage, the separately authorized $100 initial ACH payment, and RECURRING_CHARGE authorization plus subsequent $75 monthly ACH collections? If production needs separate enablement or onboarding, please tell us the exact next step and a private channel for any identifiers you need.

We also offer a card alternative: a separately authorized $100 initial payment, then a separate card-on-file authorization for 18 monthly $75 payments, with the first installment 14 days after the initial payment is confirmed completed. Does this standard recurring card-on-file flow require any additional production approval beyond our existing working online card checkout, and is there a supported read-only API or Dashboard check that establishes the required capabilities?

Please distinguish the production ACH and card requirements in your reply. We have not enabled live lease collections. Please do not rotate credentials or alter our existing ordinary card checkout. Thank you.

7

Enabling RECURRING_CHARGE in production is a separate step and requires your production app id.

In the meanwhile, we are currently reviewing the onboarding process for the recurring ACH and might need additional review process to enable this in production. I’ll get back to you once this is finalized.

As for your card alternative solution, this does not require any additional production approval because it’s a standard recurring card-on-file flow as long as you obtain the customer’s permission to save and charge the card.