Duplicate Detection

Overview

Duplicate Detection protects payment systems from repeated submission, delivery, or processing. Potential duplicates can appear when a customer clicks twice, a client retries after a timeout, a webhook is redelivered, or a batch file is imported more than once.

Strong detection uses stable unique identifiers when available. A provider transaction ID, order reference, event ID, or idempotency key is more reliable than comparing amount and timestamp alone. Payload hashes can support detection but must account for fields that legitimately change between attempts.

The detector should classify the suspected duplication layer. A Duplicate Event may be the same notification delivered twice, while a Duplicate Transaction can be two actual financial instructions. These conditions require different responses.

Similarity rules need a review path because false positives can suppress legitimate recurring or split payments. The system should record matching features, confidence, prior record, and final disposition rather than returning a hidden duplicate flag.

Detection is one part of Duplicate Prevention . Prevention uses idempotency, uniqueness constraints, state checks, and atomic writes to stop repeated effects. Monitoring should measure suspected duplicates, confirmed duplicates, suppressed repeats, and missed duplicate incidents.

Detection rules should be tested with known legitimate patterns such as subscriptions, split shipments, partial captures, repeated invoices, and same-amount transfers between the same parties. A model tuned only on obvious double clicks can over-block valid business activity. Teams should review false-positive and false-negative samples, adjust thresholds by workflow, and retain an explicit reason for every automatic duplicate decision.

High-risk matches can be held before value moves, while lower-confidence matches can be flagged without blocking. The response should be proportional to both confidence and financial consequence.