Multivaluta-ondersteuning: prijzen, betalingen, afronding en weergave

Multivaluta-ondersteuning betekent dat een klant in Tokio, Frankfurt en Chicago elk een prijs ziet in de eigen valuta, geformatteerd zoals zijn markt het verwacht, berekend zonder afrondingsfouten. Het lijkt een weergaveprobleem. Het is in werkelijkheid een probleem van gegevensopslag en bedrijfslogica vermomd als weergaveprobleem, en de meeste bugs in dit domein komen doordat teams de eerste twee overslaan en meteen naar het formatteren springen.

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. Wat "multivaluta" echt vraagt: waarom omrekening tegen de dagkoers geen echte multivaluta-prijzen oplevert, hoe je bedragen opslaat zonder afrondingsfouten in zwevende komma, waarom het aantal decimalen per valuta verschilt, en hoe afrondingsregels per markt verschillen.

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. Een systeem dat prijzen bij elke aanvraag opnieuw tegen de actuele wisselkoers berekent, kan prijsinstabiliteit veroorzaken; of dat geschikt is, hangt af van het prijs- en betalingsmodel. Wisselkoersen veranderen bovendien voortdurend door economische gegevens, besluiten van centrale banken, geopolitieke gebeurtenissen en veranderingen in het marktsentiment; die schommelingen kunnen marges, kasstromen en internationale prijsvergelijkingen beïnvloeden, aldus Stripe. Echte multivaluta-prijzen stellen een beheerste prijs per markt vast, bewust herzien en aangepast, niet bij elke paginalading opnieuw berekend. 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; voor andere betaal-API's en databases moet de representatie afzonderlijk worden gecontroleerd. Regel dit één keer goed, op de laag van database en API, en een belangrijke categorie bugs van één cent te veel of te weinig voorkom je zo grotendeels.

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. ISO 4217 documenteert voor elke valuta de verhouding tot haar minor unit (de kleinste eenheid), maar de toepasbare betaal- en afrondingsregels kunnen daarnaast afhangen van instrument, markt en regelgeving; het aantal decimale posities verschilt per valuta en moet worden ontleend aan de actuele ISO 4217-gegevens:

• 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, niet in honderdsten.

Een prijsmotor die hard is vastgelegd op twee decimalen, verminkt in stilte elke yenprijs die hij aanraakt en kapt elke dinarprijs af. Controleer daarom de toepasselijke minor unit in een onderhouden standaardtabel in plaats van overal twee decimalen te veronderstellen; afronding die de valuta kent is geen randgeval, maar de basis om meer dan een handvol markten correct te bedienen.

Afrondingsregels verschillen per markt, niet alleen per valuta

Zelfs binnen één valuta kunnen afrondingsconventies verschillen per markt en per betaalmethode. Zwitserland wordt vaak als voorbeeld genoemd: de Zwitserse frank verdeelt zich op papier in 100 centimes, maar bij contante betalingen kan afronding op de dichtstbijzijnde 0,05 CHF gelden, een conventie die vaak Zwitserse afronding of Rappenrundung heet; controleer de actuele wettelijke en betaalmethode-specifieke regels voordat je dit als algemene regel implementeert. Voor contante betalingen moet een systeem in het algemeen rekening houden met de lokaal geldende afrondingsregel: wanneer de kleinste munt in omloop groter is dan de wettelijke kleinste eenheid, wordt het te ontvangen bedrag doorgaans op de dichtstbijzijnde beschikbare afronding aangepast, aldus Shopify. Een kassa die een prijs toont die niet op die stapgrootte is afgerond en dat bedrag vervolgens contant int, kan in zo'n markt technisch onjuist uitkomen.

De les reikt verder dan dit ene voorbeeld: afronding is een bedrijfsregel die per markt en betaalmethode kan gelden, geen universele wiskundige functie. Afronding van contant geld wordt doorgaans toegepast op het eindtotaal nadat kortingen en belastingen zijn verwerkt; de precieze stapgrootte hangt af van de lokale muntpraktijk. Een multivaluta-systeem heeft daarom een afrondingsbeleid per markt nodig, niet één globale aanroep van .toFixed(2), anders levert het 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 is de locale, niet alleen de valuta, die daar de uitkomst bepaalt. De weergegeven notatie verschilt per locale: hetzelfde bedrag in dezelfde valuta kan bijvoorbeeld als $1,234.56, € 1.234,56 of 1 234,56 € verschijnen, afhankelijk van markt en conventie; laat een locale-aware formatter de exacte conventie bepalen in plaats van vaste voorbeelden als universele regel te behandelen. 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, onderdeel van de ECMAScript Internationalization API-specificatie voor het formatteren van getallen volgens taal- en cultuurconventies, gevoed door dezelfde CLDR-localedata die ook het correct formatteren van datums en getallen aanstuurt (decimaalteken, groepsscheidingsteken en de positie van het valutasymbool zijn daarin locale-afhankelijk), levert een uitkomst voor een gegeven 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.

Veelgestelde vragen over multivaluta-ondersteuning

Wat betekent multivaluta-ondersteuning eigenlijk?

Het betekent dat klanten prijzen zien in hun eigen valuta, berekend met een beheerste prijs per markt in plaats van een omrekening tegen de dagkoers, opgeslagen zonder afrondingsfouten in zwevende komma, en geformatteerd zoals hun markt het verwacht.

Moet ik prijzen omrekenen tegen een live wisselkoers?

Een live wisselkoers kan geschikt zijn voor bepaalde prijs- en betalingsmodellen, maar vaste marktprijzen zijn vaak wenselijk wanneer prijsstabiliteit en margecontrole vooropstaan; de keuze hangt af van het contract, de gateway en de markt. Live koersen zijn in elk geval nuttig voor interne rapportage en om te bepalen welke prijs een markt zou moeten dragen.

Waarom hebben sommige valuta's drie decimalen?

Valuta's als de Bahreinse en de Koeweitse dinar splitsen zich in duizendsten in plaats van in honderdsten, volgens de norm ISO 4217. Software die overal twee decimalen veronderstelt, kapt deze valuta's af of rondt ze verkeerd af.

Wat is de veiligste manier om prijzen in een database op te slaan?

Als een geheel getal in de kleinste eenheid van de valuta: centen voor een valuta met twee decimalen zoals de euro, geen onderverdeling voor een valuta met nul decimalen zoals de Japanse yen. Reken pas om naar een decimaal bij het tonen van het bedrag, nooit voor opslag of berekening.

Hoe laat ik multivaluta-prijzen correct bouwen voor mijn winkel?

Neem het vanaf het begin mee in de scope: prijsopslag, afrondingsregels per markt en weergave afgestemd op de locale zijn architectuurbeslissingen, geen kassaplug-in. Vraag een offerte met vaste prijs aan en wij bouwen de valutalaag als kern van het systeem, niet als lapmiddel achteraf.

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 →