Payment duplicated, stale or webhook never processed

Prerequisites and authority

Start with read-only checks and authorized records. Capture evidence before changes. Stop and escalate when data replacement, financial changes or wider outages are possible.

Payment duplicated, stale or callback missing

Basic

Compare references, provider transaction IDs and amounts. Two different successful payments are not the same as two deliveries of one event. A pending checkout may have been deliberately reused within a supported reuse window.

Intermediate

Inspect provider delivery and verification results, stored payment, linked subscription and payment-worker operations. Confirm the stable endpoint is still valid and reachable without an interactive login wall.

For Bachs, verify the configured environment and merchant organization ID, the saved API/signing secrets and /api/v1/payments/webhooks/bachs on the stable public API origin. The credential test is not a webhook delivery test. Check the provider delivery result, linked gateway events and the current payment-worker run separately.

A crypto amount-mismatch error can indicate incorrect integration logic comparing an asset charge to the fiat checkout price. Compare the original plan price with the checkout's amount/currency, then examine the linked charge's asset amount, paid amount and remaining amount. Do not bypass verification or mark a payment successful merely because the hosted page says it completed. Update to the release with crypto-aware verification and retry supported verification of the same payment, without creating another charge.

An unknown bachs provider enum or missing webhook table/credential column indicates an outdated runtime or unapplied additive migration. Use the supported release update/migration path and restart API/payment-worker containers with the matching image. Do not delete payment history or change enum values by hand. A retained notification may be historical; confirm the latest worker result before intervening.

Advanced

Trace idempotency/concurrency errors around the same reference. Compare event time and processing time. Check database uniqueness failures without deleting records to hide them.

Use supported reconciliation after establishing the provider's true result. Refunds and compensation require the organization's authorized financial procedure; they are not implied by deleting a record or cancelling an entitlement.

Verify one entitlement per intended transaction and no second grant from event replay. Retain financial/audit history. If the economic outcome remains uncertain, stop retries/manual payments and escalate with references and provider evidence.