Disable ACH retries after failed ACH payment

Objective

• After an ACH payment fails, stop presenting ACH as a viable retry path and steer the client toward card repayment (with existing flexibility such as waiving technology fees when appropriate).
• Reduce repeated ACH failures and inconsistent follow-up on failed ACH/EFT.

Background

• Operations feedback: failure notifications and job re-lock behavior are improving, but retry UX still invites the same failed rail.
• Product preference discussed in transcript: disable ACH after failure for the retry journey while keeping card available.

Scope

Frontend

• Client payment surfaces under attik-frontend/src/app/client/job/[slug]/pay-beta/ (PaymentBetaClient.tsx, components/ACHTab) and legacy pay/PaymentFormClient.tsx are where ACH vs card choice is presented.

Backend

• Payment status transitions and webhooks that mark ACH failed should expose enough state for the UI to hide or disable ACH on retry (attik-backend payment routes and models—pair with whatever field already tracks failure reason).

References

• attik-frontend/src/app/client/job/[slug]/pay-beta/PaymentBetaClient.tsx
• attik-frontend/src/app/client/job/[slug]/pay-beta/components/ACHTab
• attik-backend/tests/unit/payment.statusCheck.test.ts (ACH status behavior)

---

Original description

After an ACH payment fails, disable ACH as a retry option and guide the client to repay by card instead.

Transcript Context

The transcript covered failed ACH and EFT payments that were not being followed up consistently and discussed the improved flow once Attik receives failure notifications and relocks the job. Catherine and Sarah pointed out that when a failed ACH customer is asked to pay again, the system should not keep offering the same ACH path because that can lead to repeated failures. The preferred behavior discussed was to disable the ACH option after failure so the repayment flow pushes the client toward card payment, with the option to waive the technology fee if needed.