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 el propietario de la integración con Mollie, el alcance PCI y la reconciliación mediante webhooks.

Métodos admitidos

En producción actualmente:

• Tarjeta (Visa, Mastercard) y débito directo bancario en 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. Es posible 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 zona euro.

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, en paralelo a la máquina de estados del pedido en la aplicación de menú:

Cancelled y Expired son recuperables — el 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 — el cliente nunca ve un segundo proceso de pago para la propina. Una vez que el pago se liquida, la propina aparece en su 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 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 mediante token Bearer, con 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á operando un despliegue de Fooodo, el secreto de la aplicación de menú se aprovisiona durante la incorporación. Si está integrando con Fooodo como socio, normalmente no verá ninguno de los dos.

Lo que ven los socios

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

• Usted llama a la API de creación de pedidos de la aplicación de menú.
• Recibe un pedido y (cuando se requiere pago) una URL de pago.
• No gestiona datos de tarjetas, no llama a Mollie, no necesita 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 son una acción del operador — los clientes no pueden solicitarlos desde la aplicación. Según el despliegue, los reembolsos se emiten desde el panel de Mollie o desde el panel de administración del servicio de pagos. Actualmente no existe ningún flujo de reembolso orientado al cliente.