POST /commitments-v2/:id/payments kept throwing a 400 — "Must have a pending payment to submit a payment." But the payment itself had already succeeded. The investor was told it failed, so they retried, and every 400 was captured to Sentry as an error, generating false alerts.
Sentry issue INVEST-API-27Q: 38 occurrences, first seen July 2025, still ongoing — 19 events across 8 distinct sessions in the last two months. The agent cross-checked all 8 sessions against CloudWatch.
Two endpoints acknowledge a payment, with different idempotency contracts:
PENDING payment, or it throws 400.Once a payment leaves PENDING, any further manual acknowledge 400s. It left PENDING either because Plaid acknowledged it first (6 of 8 sessions) or because the investor's first tap succeeded and the button was tapped again (2 of 8, including the web app). So it was never Plaid-specific or mobile-specific: one non-idempotent endpoint plus a confirm button that can fire twice.
Make the manual acknowledge idempotent — mirror the Plaid path: if the commitment already has an acknowledged payment, return it as success instead of throwing. That covers 100% of occurrences regardless of how the payment was acknowledged. A client follow-up stops leaving the confirm button live after acknowledgement.
The spurious 400 and its false Sentry alerts are gone; investors are no longer told a successful payment failed, so the retries stop too. A whole class of noisy, misleading errors removed by making one endpoint idempotent.