Halkali merkez neighborhood fatih st ozgur apt no 46 , Kucukcekmece , Istanbul , 34303 , TR
If your website currently works only in TRY, we can add USD, EUR, GBP and other currencies without replacing the application. Rates can be fetched from TCMB or another approved source and combined with margins, scheduled updates, rounding and payment rules.
The software does not need to have been purchased from Eka Sunucu or Eka Yazılım. Open-source/custom PHP applications and platforms with suitable APIs can be evaluated.
TCMB, margins, cron scheduler and multi-currency sync
A site may show an approximate USD/EUR conversion while still creating and charging the order in TRY. Real multi-currency checkout also requires order currency, locked exchange rate, payment-provider currency support and refund/accounting logic.
The implementation is adapted to the existing price and order architecture rather than forcing one generic plugin.
Multi-currency can mean different financial behavior. We first select the correct model.
TRY remains the base charge while visitors see converted values.
The order and payment use the selected currency.
Base cost stays in USD and TRY is generated automatically.
TCMB publishes indicative exchange-rate data that can be consumed by an application and cached locally.
A production integration must decide which rate field is used, how Unit is interpreted, what happens on holidays and what fallback is applied when the source is unavailable.
The business may apply its own commercial margin on top of the source rate.
The legal/financial base price can stay in TRY while the visitor sees an approximate USD or EUR equivalent.
Checkout can still create a TRY order, avoiding changes to payment and accounting flows.
The UI should clearly distinguish an approximate display currency from the actual charge currency.
Real foreign-currency checkout requires currency code, source price, converted amount and rate snapshot in the order.
The payment provider must explicitly support the selected currency for the merchant account.
Refunds, coupons, shipping and taxes must preserve the order-time financial state.
Historical orders must not change when today's rate changes.
Store the rate and currency used at checkout as immutable order data.
Pending-bank-transfer orders may additionally need an expiry policy for quoted rates.
A percentage or fixed adjustment can be defined per currency or product group.
Formula order matters: rate conversion, margin, tax and rounding must be deterministic.
Frontend and backend should use the same calculation service to avoid cent differences.
Fetching the remote rate on every page view creates latency and dependency risk.
Use cron/scheduler to refresh rates and persist the last successful value with a timestamp.
If the source fails, keep the last valid rate and alert the administrator when it becomes stale.
Supplier feeds can provide product prices in USD or EUR. The import can read currency and convert through the same rate engine.
Business-specific formulas can apply purchasing margin, tax and sales margin after conversion.
This combines supplier XML integration with automatic FX handling.
Showing a currency does not guarantee the gateway can charge it.
Checkout must validate the gateway's supported currencies and merchant permissions.
Webhook/callback verification should validate both amount and currency.
Language, country and currency are separate concepts and should not be treated as the same preference.
For distinct country/currency offers, URL and structured-data strategy should keep displayed prices consistent.
Google product guidance recommends separate URLs when the same product is offered in multiple currencies.
Send the website URL, platform, current base currency, currencies to add and payment provider.
The first stage can identify whether display-only, real multi-currency, TCMB automation or XML+FX integration is appropriate without asking for passwords.
If source inspection is necessary, the required access is explained separately.
Values are examples. Production domains, currencies and formulas must match the application.
Turkey (Turkish)
Germany (German)
Worldwide (English)
<Currency CrossOrder="0" Kod="USD" CurrencyCode="USD">
<Unit>1</Unit>
<CurrencyName>US DOLLAR</CurrencyName>
<ForexBuying>47.4881</ForexBuying>
<ForexSelling>47.5736</ForexSelling>
</Currency>source_rate = 47.5736
margin = 2.5
applied_rate = source_rate * (1 + margin / 100)
result = 48.76294USD
Source: TCMB
Field: ForexSelling
Auto Update: Enabled
Interval: 60 minutes
Margin: 2.5%
Rounding: 0.90
Fallback: Last valid rateSend the website, currencies you want and current payment provider. We can identify the correct integration model before requesting access.
We prioritize TCMB and Google Search Central for rate-source and search guidance.
Currency automation can work with XML imports, payment integration and multilingual sites.
Answers to common implementation questions.
Yes, when the application can retrieve and store the source data.
Usually no; scheduled refresh plus local storage is more robust.
Yes. That is a display-only conversion model.
Only if the payment provider and merchant account support it.
Yes, per currency or product group.
Yes, with deterministic rounding rules.
Use a last-good-rate fallback and optional manual override.
Yes, XML import and the FX engine can work together.
It should not; the order-time rate is stored.
Yes, when the platform is technically accessible or exposes suitable APIs.
No.
Website, platform, base currency, desired currencies and payment provider.
Send the website, currencies you want and current payment provider. We can identify the correct integration model before requesting access.