>>> [!note] Migrated issue <!-- Drupal.org comment --> <!-- Migrated from issue #3614215. --> Reported by: [mably](https://www.drupal.org/user/3375160) Related to !23 >>> <p><code>PaymentManager::capture()</code>, <code>cancel()</code> and <code>refund()</code> guard on the payment state, call the gateway, and then advance the state under a row lock. The lock is on the wrong side of the network call.</p> <p>The guard is an ordinary unlocked read of the passed object. Two concurrent callers both read the same state, both pass the guard, and both reach the provider. Only one then wins the compare-and-set and announces the event. The engine records the outcome once, which is what the lock was for, but the provider was asked twice.</p> <p>For a refund or a capture the second call is real money. Worldline has no idempotency key on these requests, so nothing downstream collapses the duplicate.</p> <p><code>refund()</code> is the clearest shape: the captured-state guard, then the gateway refund call, then the CAPTURED to REFUNDED transition. Both callers refund at the provider; one records it.</p> <p>The comment in <code>capture()</code> already describes the race and reads it as benign, saying that two callers each reach the gateway but only one advances the state and announces the capture. That is accurate about the event and about the local record. It is the provider side that is not covered, and the comment should not be the reason this looks settled.</p> <p>The window needs genuine concurrency, so it is narrow: a workflow settle step racing an operator, a double-submitted back-office action, two cron-adjacent jobs. The comment in <code>capture()</code> names the first of those as a real scenario.</p> <h3>Why the create paths do not have this</h3> <p><code>authorizeToken()</code> and <code>chargeToken()</code> are already correct. They serialize on <code>lockedCreate()</code>, which acquires the lock and re-checks for an in-flight record <em>before</em> anything touches the gateway. The pattern to apply is the one the module already uses one method over.</p> <h3>What needs deciding</h3> <p>The fix is to claim the payment before the provider call rather than after, but the shape is a design decision and worth settling in the issue before any code:</p> <ul> <li>A locked compare-and-set into an in-progress state before the gateway call, which needs a state to move into and an answer for what happens to a payment whose process dies mid-call.</li> <li>A named lock around the whole operation, in the shape of <code>lockedCreate()</code>, which needs no new state but serializes rather than rejects, so the loser waits and then finds the work done.</li> <li>An idempotency key carried to gateways that support one, which is the only option that also protects against a retry from outside the engine, but which not every provider offers and so cannot be the whole answer.</li> </ul> <p>Holding a row lock across the provider call is not an option: the SDK exposes no connect or read timeout, so a hung provider would hold a database lock for as long as it hangs.</p> <p>Whichever shape is chosen has to leave the operations idempotent from the outside, since a duplicate webhook and a duplicate browser return are normal and are currently absorbed correctly.</p>