{
  "version": "2",
  "id": "https://freelancenews.online/news/developer-flags-fx-drift-between-card-authorization-and-delayed-d9a64933",
  "title": "Developer Flags FX Drift Between Card Authorization and Delayed Capture",
  "summary": "A cross-border order authorized in euros and settled in dollars came back higher at capture four days later, and the developer says nothing in the payment API response flagged the change.",
  "body": "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.\n\nIn 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.\n\nA 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.\n\nThe 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.\n\nThe 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.\n\nThe 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.\n\nFor 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.\n\nThe 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.\n\nThe 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.\n\nWhat 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.\n\nThe 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.\n\nThere 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.\n\nFor 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.\n\nThe 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.\n\nFreelancers 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.",
  "category": "dev",
  "language": "en",
  "datePublished": "2026-10-05T05:17:47.234Z",
  "dateModified": "2026-10-05T05:17:47.234Z",
  "eventDate": null,
  "sourcePublicationDate": "2026-10-02T00:00:15.000Z",
  "source": {
    "name": "dev.to",
    "url": "https://dev.to/payneteasy/the-fx-rate-nobody-locked-between-auth-and-capture-3n5d",
    "kind": "community"
  },
  "practicalImpact": "Editorial interpretation: freelancers and small studios that capture payment on delivery rather than at checkout should treat the authorization-time rate as a record worth keeping. Comparing it against the settlement report, with an explicit tolerance for small drift, is the practice this developer describes; it is one account, not a validated method, and the post does not specify a cap or name a processor.",
  "limitations": "Single first-person account on a community platform, not independently verified. The processor, acquirer and card network are not named. The 24-to-72-hour window is described as varying by processor, not as published documentation. No processor documentation, second report or measurement beyond the author's own figures is supplied. The post does not state whether the customer was refunded or otherwise made whole, and the closing question about repricing, refunding or absorbing the delta is left unanswered in the evidence.",
  "keyPoints": [
    "A developer reports that a card authorized in EUR and captured four days later in USD came back higher than the checkout amount after the EUR/USD rate moved about 1.1%.",
    "The author attributes the change to a processor-dependent authorization hold window, usually 24 to 72 hours, after which some acquirers recalculate at the current rate.",
    "The author says the API response does not flag the recalculation, leaving the discrepancy to be absorbed or raised as a false mismatch alert in reconciliation.",
    "The author's mitigation was to record the authorization-time rate and compare it line by line against the settlement report, absorbing small drifts under a fixed cap."
  ],
  "review": {
    "status": "source-reviewed",
    "checkedAt": "2026-10-05T05:17:47.234Z",
    "method": "Automated comparison against retrieved source text; not independent fact-checking.",
    "correctionNote": null
  },
  "sources": [
    {
      "id": 1,
      "url": "https://dev.to/payneteasy/the-fx-rate-nobody-locked-between-auth-and-capture-3n5d",
      "publisher": "dev.to",
      "title": "The FX rate nobody locked between auth and capture",
      "publishedAt": 1790899215000,
      "fetchedAt": 1791177453760,
      "hash": "bbdbf654e43336cc1e3aab34e610d6d09b666e7a9a58809a0361c1198987a22e",
      "kind": "community"
    }
  ],
  "claims": [
    {
      "claim": "The author reports a card authorized in EUR and captured four days later in USD, with the EUR/USD rate moving about 1.1% in between.",
      "source": 1,
      "id": "claim-1",
      "url": "https://freelancenews.online/news/developer-flags-fx-drift-between-card-authorization-and-delayed-d9a64933#claim-1"
    },
    {
      "claim": "The author states the captured amount came back higher than the checkout figure and did not match the customer's statement.",
      "source": 1,
      "id": "claim-2",
      "url": "https://freelancenews.online/news/developer-flags-fx-drift-between-card-authorization-and-delayed-d9a64933#claim-2"
    },
    {
      "claim": "The author says card networks guarantee the authorization hold in the cardholder's currency only for a processor-dependent window, usually 24 to 72 hours.",
      "source": 1,
      "id": "claim-3",
      "url": "https://freelancenews.online/news/developer-flags-fx-drift-between-card-authorization-and-delayed-d9a64933#claim-3"
    },
    {
      "claim": "The author says some acquirers recalculate the conversion at capture time using the current rate once that window passes.",
      "source": 1,
      "id": "claim-4",
      "url": "https://freelancenews.online/news/developer-flags-fx-drift-between-card-authorization-and-delayed-d9a64933#claim-4"
    },
    {
      "claim": "The author states nothing in the API response flags the recalculation, leaving reconciliation to absorb the difference or raise a false mismatch alert.",
      "source": 1,
      "id": "claim-5",
      "url": "https://freelancenews.online/news/developer-flags-fx-drift-between-card-authorization-and-delayed-d9a64933#claim-5"
    },
    {
      "claim": "The author's mitigation was to capture the FX rate at authorization and compare it against the settlement report line by line, absorbing small drifts under a fixed cap.",
      "source": 1,
      "id": "claim-6",
      "url": "https://freelancenews.online/news/developer-flags-fx-drift-between-card-authorization-and-delayed-d9a64933#claim-6"
    },
    {
      "claim": "The author asks other developers running delayed capture across currencies whether they reprice at capture, refund the delta, or absorb it below a threshold.",
      "source": 1,
      "id": "claim-7",
      "url": "https://freelancenews.online/news/developer-flags-fx-drift-between-card-authorization-and-delayed-d9a64933#claim-7"
    }
  ],
  "formats": {
    "html": "https://freelancenews.online/news/developer-flags-fx-drift-between-card-authorization-and-delayed-d9a64933",
    "markdown": "https://freelancenews.online/news/developer-flags-fx-drift-between-card-authorization-and-delayed-d9a64933.md",
    "json": "https://freelancenews.online/news/developer-flags-fx-drift-between-card-authorization-and-delayed-d9a64933.json"
  }
}