Una sola capa de pagos, muchas pasarelas: WeChat Pay y Alipay en el POS de Odoo
Si operas retail en China, la pregunta de pago realmente no es una pregunta. Los clientes pagan con WeChat Pay y Alipay, en el mostrador, con la app. Lo interesante es qué hay detrás de ese toque, y si la forma en que lo conectas a Odoo seguirá en pie después de tu tercera tienda, tu segundo proveedor de pagos, y tu próxima actualización de Odoo.
La mayoría de los primeros intentos no llegan tan lejos. Aquí está el porqué, y cómo se ve realmente una versión que perdura.
La solución puntual que no escala
Un primer intento común es un flujo low-code que firma la solicitud y llama a la pasarela. Funciona bien en la demo. También tiende a descomponerse por razones que no tienen nada que ver con los pagos y todo que ver con la disciplina de ingeniería. El secreto de firma del comercio termina viviendo en línea dentro del flujo. El entorno de ejecución se actualiza solo sin nada fijado, así que un cambio que no hiciste puede romper producción. El momento incómodo en que un cliente todavía está tecleando un PIN se maneja con una maraña de pasos condicionales y sin registro duradero de lo que pasó. Los reintentos y la conciliación son difíciles de expresar de forma confiable. Y cada cliente nuevo significa reconstruir todo el flujo a mano, sin nada probado con pruebas unitarias y sin ningún estado que puedas conservar.
Nada de eso es un problema de pagos. Es un problema de "construimos un producto a partir de un prototipo", y es exactamente la trampa que Majorbird se propuso eliminar.
Un contrato, muchas pasarelas
El principio de diseño es simple: el POS de Odoo debería hablar un solo lenguaje neutral, sin importar qué proveedor esté del otro lado. Así que el lado del punto de venta habla con un único contrato HTTP con un vocabulario pequeño y fijo: pagar (referencia del pedido, monto, el código escaneado, la pasarela destino), consultar o sondear, reembolsar, cancelar, más un proxy en bruto como válvula de escape para el caso inusual.
El estado del pago se normaliza en un único conjunto de estados al que se mapea cada pasarela: creado, pagando, pagado o fallido o cancelado, luego reembolsando, reembolsado o parcialmente reembolsado. El detalle específico y desordenado de cada proveedor, el algoritmo de firma, los nombres de campo, cómo se formatean los montos, qué endpoint llamar, se aísla dentro de un módulo por pasarela y se mantiene detrás de un registro.
Eso es lo que hace que "un solo addon, muchas pasarelas" sea real en lugar de un eslogan. El método de pago de Odoo solo guarda un endpoint y qué pasarela usar. Añadir un nuevo proveedor es un módulo nuevo más una línea en el registro. El addon de POS en sí no cambia. Sin retrabajo de módulos, sin copias bifurcadas, sin compilación especial por cliente.
Por qué los pagos POS en China son un problema propio
Vale la pena ser honestos: esto es genuinamente más difícil que conectar una pasarela de tarjeta occidental, y por razones que sorprenden a la gente.
El flujo está invertido. En lugar de que el cliente escanee un código QR del comercio, el cajero escanea el código que se muestra en la app del cliente. Este es el flujo de código de barras presentado por el cliente, o micropago.
La respuesta a menudo no es inmediata. Un cargo puede confirmarse al instante, o puede quedar pendiente mientras el cliente teclea un PIN, reportado con un estado tipo "usuario pagando". No hay un sí o no sincrónico. Hay que sondear hasta que se resuelva. Igual de importante, respuestas ambiguas como "sistema ocupado" o "usuario todavía pagando" nunca deben tratarse como fallo, porque reintentar un cargo que en realidad tuvo éxito es cómo se termina cobrando doble a un cliente. Un pago que queda atascado en "pagando" más allá de un tiempo de espera tiene que revertirse automáticamente para que el dinero nunca quede varado.
La conciliación necesita tu propio libro mayor. Las pasarelas responden una transacción a la vez; no hay un "listado de ventas de hoy" en el que apoyarse, así que el sistema mantiene su propio registro duradero y concilia contra él. Y detrás del contrato único los dos proveedores son mundos distintos: WeChat Pay v2 usa XML con firma MD5 y un certificado TLS de cliente para reembolsos, mientras que Alipay usa JSON con RSA2. Todo el sentido del contrato neutral es que el cajero, y el POS de Odoo, nunca tengan que saber nada de eso.
De hack a servicio
Convertir eso en algo que puedas operar para muchos comercios es, en su mayor parte, disciplina de software ordinaria aplicada correctamente. La pasarela corre como un único servicio versionado con etiquetas de imagen inmutables, así que lo que probaste es lo que se despliega. La configuración prevalece sobre el código: las credenciales y pasarelas vienen del entorno, nada sensible está codificado a mano, y los secretos se extraen de un vault al iniciar en lugar de estar horneados en el artefacto. La lógica de firma tiene pruebas unitarias. Hay un libro mayor duradero, una red de seguridad de conciliación en segundo plano para el caso de pago atascado, un panel operativo, y respaldos que se autoverifican. Incorporar a un cliente nuevo se convierte en una lista de verificación, no en una reconstrucción.
Qué significa esto en el mostrador
Para un minorista, el resultado es silencioso, que es el objetivo. Aceptas WeChat Pay y Alipay directamente en el punto de venta de Odoo, con confirmación y reembolsos en tiempo real, y los pagos se concilian en Odoo automáticamente en lugar de que alguien empareje a mano los totales de la app de pago con las ventas al final del día. Añadir un nuevo proveedor no significa una reconstrucción a medida. El despliegue multi-tienda y multi-cliente es más rápido, el mantenimiento es menor, y el registro de pagos es auditable de principio a fin.
Hoy el addon de POS apunta a Odoo 18 Enterprise POS, mientras que el servicio de pasarela en sí es independiente de la versión de Odoo. Está planificada una migración a Odoo 19.
Nuestra opinión
Los rieles de pago de China no son la parte difícil; casi cualquiera puede hacer pasar un solo cargo una vez. La parte difícil es hacerlo de la misma manera para cada tienda, cada proveedor, y cada actualización, sin una reconstrucción cada vez y sin un cobro doble esperando a suceder. Esa es la diferencia entre una integración que funciona en una demo y una que funciona en producción, y es la misma disciplina de diagnosticar antes de construir que Majorbird aporta al resto de una implementación de Odoo.
Si estás evaluando cómo aceptar WeChat Pay y Alipay en tu POS de Odoo, o ya estás cuidando una integración puntual que está empezando a costarte, esa es una buena conversación para tener antes de que se rompa en el peor momento posible. Coméntalo con el equipo de Majorbird en odoo@majorbird.com o www.majorbird.com.