Multivaluta-ondersteuning: prijzen, betalingen, afronding en weergave

Wij doen aan meertalige softwareontwikkeling met valuta die vanaf de eerste commit correct wordt afgehandeld, want prijsbugs zijn het soort dat klanten meteen opmerken en langzaam vergeven.

Multivaluta-prijzen zijn geen omrekening tegen de dagkoers

De snelste manier om multivaluta fout te doen: één basisprijs aanhouden en die bij het afrekenen omrekenen tegen de wisselkoers van het moment. Het lijkt op multivaluta-ondersteuning. Dat is het niet, en klanten voelen het verschil binnen een paar aankopen.

Omrekenen in real time betekent dat je prijs meebeweegt met elke koersschommeling: hetzelfde product kost dezelfde klant op twee verschillende dagen een ander bedrag. Het betekent ook dat elke toeslag, elke korting en elke afrondingsbeslissing de grilligheid van de valutamarkt erft, en dat is geen systeem dat je je omzet wilt laten sturen. Echte multivaluta-prijzen stellen een beheerste prijs per markt vast, bewust herzien en aangepast. De wisselkoers voedt die beslissing. Hij neemt haar niet automatisch, in productie, bij elke aanvraag.

Dit onderscheid weegt het zwaarst in e-commerce ontwikkeling op maat, waar een klant die jouw prijs met die van een concurrent vergelijkt wil dat die prijs stabiel blijft, en waar betaalgateways in specifieke valuta afrekenen met hun eigen regels over wat ze accepteren. Datzelfde onderscheid speelt breder in een meertalige webshop, waar de valuta maar één van de lagen is die per markt moet kloppen.

Sla bedragen op als gehele getallen, nooit als zwevende decimalen

De meest voorkomende multivaluta-bug heeft niets met valuta te maken. Het is het opslaan van bedragen als een zwevend decimaal getal, wat afrondingsfouten introduceert die zich opstapelen over een winkelwagen, een belastingberekening en een betaalgateway die geen fractie van een cent duldt op een plek waar die niet hoort.

De oplossing is een decennia oude conventie die teams die nieuw zijn met het probleem nog steeds overslaan: sla elk bedrag op als een geheel getal in de kleinste eenheid van de valuta, centen voor de euro, en reken pas bij het weergeven om naar een decimale waarde. Stripe documenteert bedragen voor zijn API in de kleinste valuta-eenheid als geheel getal, nooit als zwevend getal, precies om die reden. Regel dit één keer goed, op de laag van database en API, en een hele categorie bugs van één cent te veel of te weinig bestaat niet meer.

Kleinste eenheden zijn niet altijd twee decimalen

"Afronden op twee decimalen" klopt voor de Amerikaanse dollar en de euro, en is fout voor een aanzienlijk deel van de valuta's ter wereld. Het aantal decimalen, formeel de minor unit, ligt per valuta vast in de standaard ISO 4217, en het varieert meer dan de meeste engineers verwachten:

• Nul decimalen: de Japanse yen (JPY) en de Zuid-Koreaanse won (KRW) kennen in de praktijk geen onderverdeling. Een prijs van ¥ 1.000,50 is geen echt bedrag; het is een bug.
• Twee decimalen: de meeste valuta's, waaronder USD, EUR en GBP.
• Drie decimalen: de Bahreinse dinar, de Koeweitse dinar, de Omaanse rial en de Jordaanse dinar splitsen zich alle in duizendsten.

Een prijsmotor die hard is vastgelegd op twee decimalen, verminkt in stilte elke yenprijs die hij aanraakt en kapt elke dinarprijs af. Afronding die de valuta kent, gestuurd door de ISO 4217-tabel in plaats van een globale constante, is de basis om meer dan een handvol markten correct te bedienen.

Afrondingsregels verschillen per markt en per valuta

Zelfs binnen één valuta verschillen afrondingsconventies per markt en per betaalmethode. Zwitserland is het duidelijkste voorbeeld: de Zwitserse frank verdeelt zich op papier in 100 centimes, maar contante betalingen worden afgerond op de dichtstbijzijnde 0,05 CHF, een conventie die vaak Zwitserse afronding of Rappenrundung heet, omdat de munt van vijf centimes de kleinste is die nog in omloop is. Kassasystemen zoals dat van Shopify passen die afronding daarom toe op het te ontvangen bedrag. Een kassa die 19,98 CHF toont en dat bedrag vervolgens contant int, zit technisch fout in een markt die 20,00 verwacht.

Afronding is een bedrijfsregel per markt. Een multivaluta-systeem heeft een afrondingsbeleid per markt nodig. Eén globale aanroep van .toFixed(2) levert prijzen op die numeriek dichtbij en lokaal fout zijn.

Valuta tonen zoals elke markt het verwacht

Het formatteren is het deel dat gebruikers echt zien, en het zijn de locale en de valuta die daar de uitkomst bepalen. Hetzelfde bedrag in dezelfde valuta verschijnt als $1,234.56 in de VS, als € 1.234,56 in Vlaanderen en Nederland en als 1 234,56 € in Frankrijk, met een spatie als duizendtalscheiding. Positie van het symbool, decimaalteken en groepsscheidingsteken variëren elk los van de valuta die wordt getoond.

Moderne platforms hoeven deze logica niet met de hand te bouwen. De API Intl.NumberFormat, gevoed door dezelfde CLDR-localedata die ook datums en getallen correct formatteert, levert de juiste uitkomst voor een combinatie van valuta en locale, zonder een opzoektabel die je zelf hoeft te onderhouden. Een $-voorvoegsel en een duizendtalregel met komma hard vastleggen is de lapmiddel-versie van dit probleem: het werkt voor één markt en breekt in stilte voor elke andere. Test de uitkomst per doelmarkt. Het is dezelfde discipline die achter Unicode en tekencodering zit: locale-correcte verwerking, of het nu om bedragen of om letters gaat.

Er komen nog steeds valutasymbolen bij. Unicode 18.0, uitgebracht op 16 september 2026, voegt er drie toe: U+20C2 RUFIYAA SIGN, U+20C3 UAE DIRHAM SIGN en U+20C4 OMANI RIAL SIGN. Een nieuw codepunt betekent niet dat alle lettertypen en platforms het al kunnen tonen, dus houd de ISO-valutacode als terugvaloptie bij die bedragen.

Veelgestelde vragen over multivaluta-ondersteuning

Valutabeheer dat niet breekt bij groei

Vertel ons welke markten en valuta's je software moet ondersteunen. Wij ontwerpen prijsstelling, afronding en weergave correct vanaf de eerste commit, en komen terug met een vaste prijs en een leverdatum.

Vraag een offerte met vaste prijs aan →