Pagos

Fooodo separa la gestión de pagos en un servicio dedicado. La aplicación de menú orientada al cliente actúa como proxy hacia él; el servicio de pagos es propietario de la integración con Mollie, el alcance PCI y la reconciliación de webhooks.

Métodos admitidos

En producción actualmente:

• Tarjeta (Visa, Mastercard) y débito directo bancario de la UE
• Apple Pay
• Google Pay
• Trustly — pago directo por banca en línea, principalmente para los mercados nórdicos y bálticos donde la autenticación mediante aplicación bancaria es el flujo habitual del consumidor

El catálogo completo de métodos de Mollie está técnicamente disponible a través de la misma integración; solo los métodos anteriores están conectados al flujo de pago en producción. Se pueden habilitar métodos adicionales (p. ej., iDEAL, Bancontact) por despliegue.

El efectivo se admite como un flujo independiente: un camarero cobra en efectivo en la mesa y marca el pedido como pagado directamente en el panel de administración de Fooodo. El pedido en sí fluye a través de la misma máquina de estados; únicamente se omite el paso de creación del pago en Mollie.

Divisas admitidas

Fooodo liquida cada pedido en la divisa configurada en el restaurante. Mollie admite más de 30 divisas; la lista práctica para los mercados a los que Fooodo da servicio hoy:

El catálogo completo de Mollie (31 divisas, incluidas AUD, CAD, JPY, ZAR) está técnicamente disponible; no todos los métodos de pago cubren todas las divisas. EUR y las principales redes de tarjetas (Visa, Mastercard) funcionan en todas partes; la compatibilidad entre método y divisa se finaliza durante la incorporación para despliegues fuera de la eurozona.

Para los despliegues en Rumanía específicamente, RON está admitido mediante pagos con tarjeta de extremo a extremo; Apple Pay y Google Pay también aceptan tarjetas RON.

El ciclo de vida del pago

El flujo está basado en webhooks y es idempotente. Mollie puede reintentar los webhooks ante fallos transitorios; las repeticiones son seguras — el servicio hace un cortocircuito si el estado del pago no ha cambiado desde la última ejecución.

Estados del pago

El servicio de pagos mantiene su propia máquina de estados, paralela a la máquina de estados de pedidos de la aplicación de menú:

Cancelled y Expired son recuperables — un cliente puede reintentar en el mismo pedido, lo que crea un nuevo intento de pago contra el mismo pedido.

Propinas

Las propinas se agrupan en un único cargo de Mollie junto con el pedido — los clientes nunca ven un segundo proceso de pago para la propina. Una vez que el pago se liquida, la propina aparece en tu POS como una línea de propina independiente en el pedido, de modo que los flujos de informes y distribución de propinas funcionan como siempre. El código de ingresos del POS utilizado para representar los ingresos por propinas se configura por restaurante en el panel de administración (R-Keeper es el conector de referencia activo para esto; otros conectores POS exponen el mismo ajuste a través del contrato de conector).

Donaciones

Las donaciones funcionan de la misma manera: un único cargo de Mollie al cliente, pero la parte correspondiente a la donación se enruta a una cuenta de organización separada dentro de Mollie (Cruz Roja es el ejemplo de referencia activo). Desde la perspectiva del cliente es una sola transacción; desde la perspectiva del operador, la donación no aparece en los ingresos del restaurante ni en los informes de ventas del POS — se registra limpiamente en los libros de la organización asociada.

Webhooks

Intervienen dos webhooks:

• Mollie → servicio de pagos. Endpoint público que recibe únicamente un ID de pago de Mollie. El servicio llama entonces a la API de Mollie para obtener el estado autoritativo — de modo que una devolución de llamada falsificada no puede mover dinero ni cambiar el estado del pedido. (Este es el patrón de integración estándar de Mollie; sus callbacks son intencionadamente mínimos.)
• Servicio de pagos → aplicación de menú. Autenticado con token Bearer, secreto por despliegue. Este es el canal que realmente cambia el estado del pedido en el lado de la aplicación de menú.

Si estás operando un despliegue de Fooodo, el secreto de la aplicación de menú se aprovisiona durante la incorporación. Si te estás integrando con Fooodo como socio, normalmente no verás ninguno de los dos.

Lo que ven los socios

Los integradores socios no se integran directamente con el servicio de pagos. El contrato es:

• Llamas a la API de creación de pedidos de la aplicación de menú.
• Recibes un pedido y (cuando se requiere pago) una URL de pago.
• No gestionas datos de tarjetas, no llamas a Mollie, no necesitas alcance PCI.

Esta es una de las razones fundamentales por las que el servicio de pagos existe como un límite separado.

Reembolsos y reversiones

Los reembolsos no son una funcionalidad de Fooodo: no existe ninguna acción de reembolso en la aplicación de menú ni en el panel de administración del servicio de pagos. Un reembolso se emite directamente en el panel de Mollie contra el pago original, y el pedido se revierte en el POS como siempre. Los clientes no pueden solicitar un reembolso desde la aplicación.