Soporte multidivisa: precios, cobros, redondeo y visualización

El soporte multidivisa significa que un cliente en Tokio, en Londres y en Valencia ve cada uno un precio en su propia divisa, con el formato que su mercado espera, calculado sin errores de redondeo. Suena a problema de visualización. En realidad es un problema de almacenamiento de datos y de lógica de negocio disfrazado de problema de visualización, y la mayoría de los fallos del área vienen de quien se salta los dos primeros para lanzarse al formato.

Practicamos el desarrollo de software multilingüe con las divisas bien gestionadas desde el primer commit, porque los fallos de precio son de los que un cliente nota al instante y perdona despacio. Esto es lo que exige de verdad "lo multidivisa": por qué la conversión al cambio del día no es una tarificación multidivisa real, cómo almacenar importes sin errores de coma flotante, por qué el número de decimales varía según la divisa, cómo las reglas de redondeo cambian según el mercado, y qué añaden el cobro y el IVA cuando vendes desde España.

La tarificación multidivisa no es una conversión al cambio del día

La forma más rápida de fallar en lo multidivisa es guardar un único precio base y convertirlo al tipo de cambio del momento en el pago. Parece soporte multidivisa. No lo es, y los clientes notan la diferencia en unas pocas compras.

La conversión en directo hace que tu precio se mueva cada vez que se mueve el tipo de cambio: el mismo producto cuesta un importe distinto al mismo cliente dos días seguidos. También significa que cada comisión, cada descuento y cada decisión de redondeo hereda la volatilidad del mercado de divisas, y ese no es un sistema al que confiar tu facturación. Una tarificación multidivisa real fija un precio controlado por mercado, revisado y ajustado a conciencia, no recalculado en cada carga de página. El tipo de cambio informa esa decisión. No la toma solo, en producción, en cada petición.

Si te suena abstracto, piensa en la conversión dinámica de divisa (DCC), esa pantalla del datáfono que te ofrece cobrarte en tu propia divisa "para tu comodidad" con un tipo peor que el de tu banco. Es lo mismo llevado al punto de venta, y a nadie le gusta cuando lo entiende. La distinción pesa sobre todo en el desarrollo de ecommerce a medida, donde un cliente que compara tu precio con el de la competencia necesita que se quede quieto, y donde las pasarelas de pago liquidan en divisas concretas con sus propias reglas sobre lo que aceptan.

Almacena el dinero como enteros, nunca como decimales de coma flotante

El fallo multidivisa más común no tiene nada que ver con las divisas. Es guardar el dinero como decimal de coma flotante, lo que introduce errores de redondeo que se acumulan a lo largo de un carrito, un cálculo de impuestos y una pasarela de pago que no tolera que aparezca un céntimo fraccionario donde no debe.

El remedio es una convención de hace décadas que los equipos nuevos en el tema siguen saltándose: almacena cada importe como entero en la unidad más pequeña de la divisa, los céntimos para el euro, y convierte a valor decimal de visualización solo al pintar la pantalla. La propia API de Stripe funciona así por exactamente este motivo: los importes se representan en la unidad más pequeña de la divisa, en entero, nunca en coma flotante (Stripe, Working with currencies). Acierta esto una vez, en la capa de base de datos y API, y toda una categoría de fallos de un céntimo arriba o abajo deja de existir. Lo mismo vale aguas abajo, en el software de facturación a medida para pymes: una factura que no cuadra con el cobro por un céntimo es una llamada a tu gestoría.

Las unidades menores no siempre son dos decimales

"Redondear a dos decimales" es correcto para el dólar estadounidense y el euro, y falso para una parte significativa de las divisas del mundo. El número de decimales, formalmente la unidad menor, se define por divisa en la norma ISO 4217, y varía más de lo que la mayoría de los ingenieros imagina (ISO 4217):

• Cero decimales: el yen japonés (JPY) y el won coreano (KRW) no tienen subdivisión en la práctica. Un precio de 1.000,50 ¥ no es un importe real; es un fallo.
• Dos decimales: la mayoría de las divisas, entre ellas USD, EUR y GBP.
• Tres decimales: el dinar bahreiní, el dinar kuwaití, el rial omaní y el dinar jordano se subdividen todos en milésimas, no en centésimas.

Un motor de precios fijado en dos decimales corrompe en silencio cada precio en yenes que toca y trunca cada precio en dinares. El redondeo consciente de la divisa, guiado por la tabla de unidades menores de ISO 4217 en lugar de por una constante global, no es un caso límite. Es la base para cubrir bien más de un puñado de mercados.

Las reglas de redondeo varían según el mercado, no solo según la divisa

Incluso dentro de una misma divisa, las convenciones de redondeo cambian según el mercado y el medio de pago. Suiza es el ejemplo más claro: el franco suizo se subdivide en 100 céntimos sobre el papel, pero las transacciones en efectivo se redondean al 0,05 CHF más cercano, una convención a menudo llamada redondeo suizo o Rappenrundung, porque la moneda de cinco céntimos es la más pequeña que sigue en circulación. Una caja que muestra un precio de 19,98 CHF y luego cobra exactamente eso en efectivo es técnicamente errónea en un mercado que espera 20,00.

La lección va más allá de este ejemplo: el redondeo es una regla de negocio propia de cada mercado, no una función matemática universal. Un sistema multidivisa necesita una política de redondeo por mercado, no un único .toFixed(2) global, so pena de producir precios numéricamente próximos y localmente erróneos.

Cobros e IVA cuando vendes desde España

El multidivisa se cruza con dos asuntos muy españoles en cuanto sales del prototipo: cómo cobras y cómo declaras.

Del lado del cobro, los medios que tus clientes usan de verdad no son los de un manual estadounidense. La tarjeta pasa casi siempre por Redsys y por tu TPV virtual, con la autenticación reforzada de cliente (SCA) que exige la PSD2 metida en el flujo, así que tu pantalla de pago tiene que sostener un paso extra sin perder el importe por el camino. Bizum y la transferencia SEPA solo hablan euros: si tu escaparate le muestra libras a un cliente y luego le ofreces Bizum, el sistema tiene que saber qué medios existen para qué divisa antes de pintar los botones, no después.

Del lado del IVA, la divisa y el impuesto viajan juntos. En las ventas a distancia dentro de la UE, el umbral de 10.000 € es anual y de ámbito europeo, la suma de todos los Estados miembros juntos, no una cifra por país. Por debajo puedes repercutir el IVA español; por encima repercutes el del país de destino y lo liquidas por la ventanilla única (OSS) sin darte de alta en cada Estado. Las declaraciones del OSS se presentan en euros, y los importes cobrados en otras divisas se convierten con el tipo de cambio del Banco Central Europeo del último día del periodo de liquidación. Traducido a arquitectura: tu sistema tiene que guardar el importe en la divisa cobrada y su contravalor en euros con el tipo y la fecha que aplicó, o cada trimestre alguien lo reconstruye a mano en una hoja de cálculo.

Y hay una regla de visualización que cambia según a quién le vendes. Al consumidor final tienes que mostrarle el precio final, con los impuestos ya incluidos: un "desde 49 €" que en el carrito se convierte en 59,29 € no cumple. En B2B la convención es la contraria y el precio se muestra sin el impuesto, marcado como "(IVA no incluido)". Un mismo motor de precios que sirve a los dos públicos necesita saber en qué modo está antes de formatear nada.

Mostrar la divisa como cada mercado la espera

El formato es la parte que los usuarios ven de verdad, y es la configuración regional, no solo la divisa, la que decide el resultado. El mismo importe en la misma divisa se pinta distinto por convención: 1.234,56 € en España, 1 234,56 € con un espacio como separador de miles en Francia, y $1,234.56 en Estados Unidos, con la coma y el punto intercambiados y el símbolo delante. Posición del símbolo, separador decimal y separador de grupos varían cada uno con independencia de la divisa mostrada.

Las plataformas modernas no necesitan construir esta lógica a mano. La API Intl.NumberFormat, apoyada en los mismos datos de configuración regional de CLDR que guían el buen formato de fechas y números, produce la salida correcta para un par divisa-idioma dado, sin una tabla de correspondencias que mantener. Fijar en el código un prefijo de moneda y una regla de miles con coma es la versión parche de este problema: funciona para un mercado y se rompe en silencio para todos los demás. La misma disciplina que aplicas a Unicode y la codificación de caracteres vale aquí: los datos del estándar ya existen, y reescribirlos a mano solo añade formas nuevas de equivocarse.

Preguntas frecuentes sobre el soporte multidivisa

¿Qué significa de verdad el soporte multidivisa?

Significa que los clientes ven precios en su propia divisa, calculados con una tarificación controlada por mercado en lugar de una conversión al cambio del día, almacenados sin errores de redondeo de coma flotante, y con el formato que su mercado espera.

¿Debo convertir mis precios con un tipo de cambio en directo?

No para el precio que paga el cliente. Los tipos en directo sirven para los informes internos y para orientar el precio que un mercado debería llevar, pero el precio en sí debe ser un valor controlado, fijado a conciencia por mercado, no un número que sigue al mercado de divisas en cada carga de página.

¿Por qué algunas divisas tienen tres decimales?

Divisas como el dinar bahreiní y el dinar kuwaití se subdividen en milésimas en lugar de centésimas, según la norma ISO 4217. Un software que asume dos decimales en todas partes trunca o redondea mal estas divisas.

¿Cuál es la forma más segura de guardar precios en una base de datos?

Como entero en la unidad más pequeña de la divisa: los céntimos para una divisa de dos decimales como el euro, ninguna subdivisión para una divisa de cero decimales como el yen japonés. Convierte a decimal solo al mostrar el importe, nunca para el almacenamiento ni el cálculo.

¿Cómo consigo una tarificación multidivisa bien construida para mi tienda?

Métela en el alcance desde el principio: el almacenamiento de precios, las reglas de redondeo por mercado y la visualización consciente de la configuración regional son decisiones de arquitectura, no un plugin de caja. Pide un presupuesto cerrado y construimos la capa de divisas en el núcleo del sistema, no como parche posterior.

Una gestión de divisas que no se rompe al crecer

Cuéntanos qué mercados y qué divisas tiene que cubrir tu software. Diseñamos la tarificación, el redondeo y la visualización bien desde el primer commit, y respondemos con un precio cerrado y una fecha de entrega.

Pide un presupuesto cerrado →