A developer writing on dev.to has described a cross-border payment problem that surfaces only when capture is delayed: the exchange rate applied at authorization is not necessarily the rate applied when the transaction is captured days later. The account is a first-person report of one order, not an independently verified finding, and the author does not name the processor, acquirer or card network involved.
In the reported case, the card was authorized in euros, capture fired four days later once the item shipped, and the settlement currency was US dollars. The author states the EUR/USD rate moved roughly 1.1% between those two events, and that the captured amount came back higher than the figure shown to the customer at checkout. The customer's statement, the author adds, did not match the order confirmation.
A timing window is the explanation that the author puts forward. The post states that the authorization hold is guaranteed by card networks in the cardholder's currency only for a period that differs by processor, typically somewhere between 24 and 72 hours. The author writes that after that window passes, the conversion is recalculated by some acquirers at capture time using the current rate rather than the rate quoted at authorization.
The practical sting, as described, is that the recalculation is invisible in the API response. The author says nothing in the response flags the change; the developer simply receives a captured amount that is off by cents or dollars from what was authorized. That discrepancy then lands in reconciliation, where it is either absorbed silently or raised as a false mismatch alert, depending on the tolerance threshold configured.
The author's own mitigation was to capture the FX rate at authorization time and compare it against the settlement report line by line. Small drifts below a fixed cap were absorbed; anything above the cap was flagged for manual review. This is a described workflow from one developer, not a documented product feature or a published best practice.
The post closes by asking other developers running delayed capture across currencies whether they reprice at capture, refund the delta, or absorb it below a threshold. That question is left open in the source material, and no responses are included in the evidence available here.
For freelancers and small studios billing international clients through card payments, the reported mechanism matters most where fulfillment is slow. A digital product delivered instantly rarely sits in the gap; a physical shipment, a made-to-order item or a milestone-based project that captures on completion can. The longer the interval between authorization and capture, the more room there is for the rate to move against the amount the customer agreed to.
The author's framing suggests the risk is not exotic currency pairs but ordinary ones. A roughly 1.1% move over four days in a major pair is presented as unremarkable, which is precisely why the resulting discrepancy is easy to miss. On a small invoice the drift may be trivial; on a larger one it can exceed the margin on the job.
The reconciliation angle is the part most likely to affect a solo operator. A mismatch alert that fires on rate drift rather than on genuine fraud or error trains whoever reads the alerts to ignore them. The author's approach, comparing the authorization-time rate against the settlement report and setting an explicit cap, is one way to keep the signal meaningful, though the post does not specify what cap was chosen or how it was derived.
What the account does not establish is how widespread the behavior is. The author attributes the recalculation to "some acquirers" without naming them, and the 24-to-72-hour window is described as varying by processor rather than as a published standard. Whether a given merchant encounters this depends on the processor, the acquirer, the currency pair and the capture delay, none of which are enumerated in the source.
The post also does not say whether the customer was made whole. The author notes the captured amount exceeded the checkout figure and that the statement did not match the confirmation, but the evidence does not record a refund, a credit or a support outcome. The three options posed in the closing question, repricing, refunding the delta or absorbing it, are presented as open choices rather than resolved ones.
There is no indication in the source that the API response was expected to include the applied rate, only that it did not. That distinction matters for anyone reading the post as a bug report: the author is describing an absence of information, not a documented failure of a specific endpoint.
For developers building checkout flows, the reported gap points to a design question rather than a library choice. If the amount shown at checkout can differ from the amount captured, the confirmation the customer receives and the amount they are charged can diverge without either party doing anything wrong. The author's line-by-line comparison against the settlement report is one way to detect that divergence after the fact; the post does not describe a way to prevent it before capture.
The most defensible reading of the account is narrow. One developer, one cross-border order, one currency pair, one four-day delay, and a reported discrepancy of a few cents to a few dollars. The mechanism described is plausible and specific, but the evidence here contains no processor documentation, no second report and no measurement beyond the author's own figures.
Freelancers who bill across currencies and capture on delivery can take one concrete step from this account: record the rate at authorization and reconcile it against the settlement line, with a defined threshold for what counts as noise. That is the author's stated practice, offered as a question to peers rather than as a validated method, and it should be treated accordingly until a processor confirms the behavior in writing.