Skip to content

[Quality][High] Make bill-payment retries idempotent and user-visible #1631

Description

@Baskarayelu

Objective

Add a payment-attempt state machine with durable idempotency and explicit ambiguous-result handling.

Why this matters

A provider timeout can leave the user unsure whether a bill was paid, and an automatic retry can double-charge.

This is a substantive production-quality improvement. It must change runtime behavior, security guarantees, correctness, reliability, or meaningful user functionality. It is not a documentation-only, formatting-only, or trivial dependency task.

Scope

Area: bill payments

Starting points: lib/bills-reminders.ts, lib/api/error-handler.ts, components/TransactionStatusIndicator.tsx

The contributor should verify the current implementation before changing it and keep the PR limited to this issue. Do not introduce unrelated refactors or weaken existing CI/security gates.

Acceptance criteria

  • One bill occurrence has one payment identity and one terminal outcome.
  • Timeouts enter an unknown/reconciliation state rather than blindly retrying.
  • The UI distinguishes pending, paid, failed, and needs-review states.
  • A retry is permitted only when the previous attempt is proven non-terminal.

Required validation

  • Test duplicate click, timeout, provider failure, reconciliation success, and permanent failure.

  • Test refresh/reconnect during each state.

  • Add E2E coverage for a failed and recovered payment.

  • The PR explains the failure mode, the chosen design, backward-compatibility impact, and rollback or migration considerations.

  • The PR includes CI evidence and does not contain secrets, generated noise, unrelated cleanup, or disabled checks.

Contributor deliverables

  • Open a focused feature branch and do not begin implementation until assigned.
  • Reference this issue with Closes #<issue-number> or Fixes #<issue-number>.
  • Check off every acceptance criterion in the PR with links to the relevant code and tests.
  • Include a security/correctness note explaining why adversarial inputs cannot bypass the new guarantee.

Maintainer quality bar

The PR must be independently reviewable, preserve existing behavior outside this scope, exercise failure paths, and pass the repository's complete required CI/CD checks. Reward eligibility is not guaranteed by this issue or by merging.

Activity

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions