Architecting Dynamic Currency Conversion and Multi-Currency Processing

Dynamic Currency Conversion lets an eligible cardholder pay in a familiar home currency, while Multi-Currency Processing lets merchants present and process supported transaction currencies.

Supporting both requires coordinated behavior across dashboard configuration, checkout, transaction orchestration, gateways, refunds, chargebacks, and analytics.

The existing DCC path was too limited for the required compliance and transaction coverage.

Currency decisions and provider data needed one coherent contract across pre-authorization, decoupled authentication, retries, partial and split orders, voids, refunds, and chargebacks.

Network and gateway rules shaped which data could be collected, forwarded, stored, and displayed.

Merchants needed to configure FX-provider credentials without exposing sensitive values.

The design had to support hosted payment pages and API-integrated merchants while making currency choice clear to the customer.

Multiple product teams needed stable contracts that could evolve independently.

Owned the end-to-end solution design, which was reviewed with senior architects, and implemented core parts alongside payment-page, dashboard, and transaction teams.

Mapped currency behavior across the complete payment lifecycle, including the payment-page experience and frontend-backend decision contract, and converted it into shared contracts and team-level implementation boundaries.

Designed merchant-dashboard configuration for FX-provider credentials and supported currencies.

Designed the extension to the existing hosted payment page: UI states, selection precedence, and frontend-backend contracts to identify whether DCC, Multi-Currency Processing, or both apply and present a coherent currency choice without conflicting offers.

Defined the backend response needed by the payment page—eligibility, supported currencies, conversion context, and quote data—so frontend rendering and the selected transaction path stay consistent.

Defined eligibility and quote boundaries for payment-page and API-driven currency selection.

Created a common gateway-facing interface so conversion details could be delivered consistently without leaking provider-specific behavior.

Specified behavior for authorization, pre-authorization, decoupled flows, retries, partial and split orders, voids, refunds, and chargebacks.

Designed audit and analytics boundaries so useful currency data remained visible while restricted details stayed filtered.

A shared contract simplified cross-team adoption but required careful optionality so flows did not carry irrelevant currency data.

Central eligibility logic increased consistency while demanding explicit cache, failure, and provider-timeout behavior.

Established the reviewed architecture and shared contracts for a platform-wide DCC and MCP rollout.

Made the customer-facing currency decision a first-class part of the design instead of leaving DCC and MCP as disconnected backend capabilities.

Reduced ambiguity across teams by defining currency behavior for the transaction lifecycle instead of treating conversion as a checkout-only feature.

Cross-cutting payment features succeed when the lifecycle contract is designed before individual services begin implementation.

Compliance is an architectural input: it shapes data boundaries, persistence, observability, and user experience.