How to test currency conversion in cross-border payments

Cross-border payment currency conversion testing checks that a payment’s source amount is converted into the intended destination currency using the correct exchange rate, timing and rounding rules. It verifies the amounts and currencies shown to the customer, sent to payment networks and recorded in ledgers, including how fees and failures affect the transaction.

Define the expected conversion

Before writing tests, establish the conversion contract for each payment route or product. Confirm the source and destination currencies, the rate source, the quote direction, when the rate is selected, how long a quote remains valid and which party bears each fee. A rate quoted as units of destination currency per one unit of source currency produces a different calculation from its inverse.

Document whether the customer receives a firm quote or an indicative rate, and what happens if processing occurs after the quote expires. The expected behaviour may depend on the payment’s agreement and route. Record the rule as testable acceptance criteria rather than assuming that every route uses the same rate timing.

Build test cases around the calculation

Use controlled rates and amounts so that the expected result can be calculated independently. Cover ordinary values, values near a rounding boundary, small payments, large permitted amounts and applicable transaction limits. Include cases where the rate changes between quote creation and payment submission, and check whether the system honours the locked quote or obtains a new one according to the defined rules.

Check the full amount flow. The conversion may occur before or after a fee is applied, and fees may be charged in the source currency, destination currency or separately. Assert each amount and currency independently. Verify the customer confirmation, API response, payment instruction and ledger entries; a correct screen value does not prove that downstream records use the same amount.

Worked example

Assume a test quote states that 1 EUR equals 1.08765 USD. A payment of 100 EUR converts to 108.765 USD before fees. If the product’s specified rule rounds the destination amount to two decimal places using half-up rounding, the expected amount is 108.77 USD. Assert the selected rate, rate identifier or quote reference, unrounded calculation where available, rounded payable amount and any separate fee. If the product specifies another rounding rule, use that rule in the expected result.

Use decimal arithmetic in test data and assertions. Avoid calculations based on binary floating-point, which can represent some decimal fractions approximately. Keep the rate and rounding policy in the test fixture or oracle explicit so a failure can be traced to the calculation, configuration or source data.

Verify API and cross-system behaviour

For API testing, submit a payment with an agreed source amount, currency pair and quote reference. Assert the response fields for source amount, destination amount, currencies, rate and fees. Then follow the payment through the relevant status updates and inspect the resulting payment message and ledger postings. Check that retries with the same idempotency key do not create another debit or apply conversion twice.

Include negative and boundary cases: unsupported currency pairs, missing or expired quotes, malformed rates, amounts outside configured limits and a rate provider timeout. Verify the documented error or recovery path, including whether the payment remains pending, is rejected or can be retried. Confirm that a failed conversion leaves no partial posting, and that a retry cannot silently use a different rate when the original quote is meant to remain locked.

Check rounding, fees and reconciliation

Rounding can create a difference between the calculated amount and the amount posted or settled. Test the configured rounding point and method, especially where fees are converted or deducted. Reconcile amounts at each stage using the currencies recorded in the payment data. Do not compare amounts with different currencies as if they were directly equal; use the applicable rate and documented posting rules.

Run tests across relevant routes and environments with controlled rate fixtures or a test rate source. Environment drift in rate configuration, currency precision or fee tables can make the same case produce different results. Capture the quote, configuration version, request and response, payment status and ledger evidence so the outcome is reproducible. These checks complement broader [Cross-border payment testing] and [Cross-border payment reconciliation testing].