Project
FX & Local Currency Checkout
Product & Growth, Laced
I launched EU local-currency checkout at Laced, integrating real-time FX rates with caching, rate-locking at authorisation, and consistent rounding across PDP, cart, checkout, and refunds.
- I redesigned payment screens to make charged currency and rate disclosure unambiguous, and aligned tax/duties messaging so EU buyers saw a single, accurate total with no post-purchase surprises.
- EU checkout completion lifted meaningfully and FX confusion support tickets fell — with zero reconciliation errors or margin leakage on launch.
Overview
EU buyers on Laced were seeing GBP prices, mentally converting, and either dropping off at checkout or raising FX-related complaints after purchase. I led the end-to-end launch of local-currency checkout to fix that — framing it not as a currency toggle but as a trust and accuracy problem spanning pricing display, payment processing, FX risk, tax/duties communication, and refunds.
The problem
The failure was a chain. Display currency didn't match the charged currency. Totals differed between PDP, cart, and checkout. Refund amounts confused buyers when FX was involved. Any one of those breaks trust completely on a high-consideration sneaker purchase. EU funnel data showed disproportionate drop-off at the payment step, and support themes confirmed buyers didn't understand what rate had been applied or why their bank statement didn't match what they saw on screen.
What I did
I mapped the full trust surface — FX rate sourcing, caching strategy, rate-lock mechanics, rounding rules, tax and duties presentation, and refund handling — before writing a line of requirements. I validated three assumptions first: that local currency improved purchase confidence (funnel and CX evidence confirmed it), that accuracy mattered as much as UX (rounding drift in refunds was already causing chargebacks), and that we needed an explicit rate-lock strategy at authorisation to eliminate display-vs-charge mismatches.
I then designed the system around one principle: the customer sees one price and is charged that price.
Systems I built
I defined and drove delivery of the full FX checkout system:
- FX rate integration: real-time rate sourcing with a 5–15 minute cache per currency and a small buffer to protect against intra-day movement
- Rate lock at authorisation: locked FX at payment auth to eliminate display/charge mismatch; added session expiry and re-quote behaviour for stale carts
- Consistent rounding: single rounding strategy enforced across PDP, cart, checkout confirmation, and refunds — no mystery pennies
- Tax/duties trust layer: separated line items cleanly (item price, shipping, duties), accurate messaging per market (duty-included vs duty-on-delivery), and understandable refund handling when FX was involved
- Checkout UX redesign: clear statements of charged currency, rate-lock disclosure, and removal of double-currency confusion
- Phased rollout: feature-flagged launch, EUR first, with test orders across currencies, refund and chargeback simulations, reconciliation checks with Finance, and monitoring on rate service health, checkout errors, and settlement mismatches
Impact
EU checkout completion increased and payment-step drop-off fell. FX confusion support tickets reduced measurably. We launched without reconciliation errors or margin leakage — the hardest part of a payments feature is often what breaks in refunds, and we had tested every edge case before going live.