Cobrar en línea: qué ocurre entre el toque del cliente y el dinero en su cuenta

Una pasarela no mueve el dinero cuando el cliente aprueba — algunas solo lo mueven al capturar. Qué cubre cada una de Stripe, PayPal, Paymob y Fawry, por qué su moneda elige la pasarela, y por qué el webhook es la única confirmación honesta.

2026-09-237 min de lectura

Un cliente pulsa Pagar en su página de pedidos y ve una marca verde. Detrás de esa marca, cuatro o cinco cosas tuvieron que salir bien, y una de ellas decide si usted tiene realmente el dinero o solo el permiso para cobrarlo. La mayoría de las discusiones con un proveedor de pagos empiezan porque un restaurante dio por hecho que eran lo mismo.

La pasarela toma primero el consentimiento, después el dinero

Toda red de tarjetas divide un pago en dos momentos:

Autorización — el banco emisor confirma que el dinero existe y lo reserva.
Captura — el comercio dice «cóbralo ahora», y el dinero se mueve.

Algunas pasarelas unen ambos pasos por usted. Otras no, y le entregan un pedido aprobado, con fondos y completamente sin cobrar hasta que lo reclame. PayPal funciona del segundo modo: un cliente que aprueba en la página de PayPal ha consentido pagarle, y nada ha salido de su cuenta hasta que ocurre la captura. Stripe Checkout, configurado de forma habitual, hace las dos cosas por usted.

Esto importa por una razón muy práctica. Si su sistema marca un pedido como pagado en cuanto el cliente vuelve, antes o después servirá comida contra autorizaciones que nunca se capturaron — y se enterará a fin de mes, por su banco, no por su TPV.

La regla es simple y vale la pena exigirla a cualquier proveedor: una venta está pagada cuando el dinero se ha movido, no cuando el cliente ha vuelto.

Cuatro vías, y para qué sirve cada una honestamente

Vía	Alcance	Ideal para
Stripe	La mayoría de países y monedas	La opción por defecto para tarjetas fuera de Egipto
PayPal	Monedero y tarjeta, en las monedas que liquida	Clientes que prefieren no dar su tarjeta a un sitio nuevo
Paymob	Egipto	Tarjetas y monederos locales, en libras egipcias
Fawry	Egipto	Un número de referencia que el cliente paga en efectivo en cualquier punto

Fawry es la excepción útil: no acepta tarjeta en absoluto. Emite un código, el cliente lo paga en un quiosco o una farmacia, y la confirmación le llega después. En un mercado donde buena parte de la gente no tiene tarjeta, eso no es un plan B — es la vía principal.

El efectivo y el datáfono de su mostrador siguen siendo otras dos vías, sin pasarela alguna. Se registran en caja y se cuadran contra el cajón al cierre del turno.

Su moneda elige la pasarela, no su preferencia

Esta es la parte que sorprende, así que conviene decirlo claro: un proveedor liquida en una lista fija de monedas, y si la suya no está, ninguna configuración lo arregla.

Paymob y Fawry liquidan en libras egipcias. Son la respuesta correcta en El Cairo e irrelevantes en Madrid. Stripe llega a casi todas partes. PayPal llega a buena parte del mundo pero no acepta libras egipcias en absoluto, ni riales, ni dírhams — así que un restaurante egipcio con la carta en EGP no puede poner PayPal detrás de su pago, por mucho que quiera.

Un buen sistema se lo dice al configurar, no en el primer pedido fallido. A un restaurante que factura en euros no deberían ofrecerle las vías egipcias; a uno que factura en libras no deberían dejarle configurar en silencio un proveedor que rechazará su primera transacción.

Si opera en más de un país, fije precios por establecimiento en su propia moneda y deje que cada uno lleve su proveedor. Lo que nos lleva al siguiente error.

Las claves de una sucursal no son las de la central

Las credenciales de un proveedor pertenecen a una cuenta de comercio, y una cuenta de comercio liquida en una cuenta bancaria, en una moneda.

Por eso, cuando un grupo tiene una sucursal en otro país, esa sucursal no puede heredar las credenciales de la central — no por política, sino por aritmética. Esas claves dirigirían a sus clientes a un procesador incapaz de cobrar su dinero.

La disposición sensata: una sucursal que factura en la misma moneda hereda los ajustes y no necesita configuración aparte. Una que factura en otra conserva sus credenciales, su dirección de retorno y su liquidación. Pregunte a cualquier proveedor cómo resuelve esto antes de abrir el segundo país, no después.

El webhook es la confirmación

Cuando un cliente termina de pagar ocurren dos cosas independientes:

su navegador es redirigido a su página, y
el proveedor envía a su servidor una notificación firmada con lo sucedido.

Solo la segunda es fiable. Una redirección puede interrumpirse por una conexión caída, una pestaña cerrada, una batería agotada o un cliente que simplemente pulsó atrás — y en todos esos casos el dinero puede haberse movido igualmente. Peor aún: una redirección es una URL, y una URL se puede teclear.

La notificación firmada — el webhook — es el proveedor diciéndole a su servidor, de servidor a servidor y con una firma que usted verifica, que el pago se liquidó. Ese es el evento que debe marcar el pedido como pagado, liberar el tique a cocina y aparecer en la recaudación del día.

Dos consecuencias prácticas:

Su dirección de retorno debe ser alcanzable desde Internet. Un webhook es una petición entrante. No funciona contra un portátil en el WiFi de una cafetería, y por eso una prueba que pasa en la máquina de un desarrollador puede fallar en producción.
El proveedor enviará el mismo evento dos veces. Las redes pierden confirmaciones y todo proveedor serio reintenta. Tenerlo en cuenta es lo que evita que un pedido se registre como dos pagos.

Las devoluciones vuelven por la misma vía

Una devolución no es una transferencia de vuelta — es una instrucción a la vía original para revertir un cargo concreto. Eso significa que solo puede devolver por el proveedor que cobró, y normalmente necesita la referencia de la captura, no la del pedido.

De ahí se siguen dos cosas. Primera, una devolución en efectivo y una por pasarela son operaciones distintas y deben verse distintas en sus informes, porque una vacía un cajón y la otra ajusta una liquidación bancaria. Segunda, una devolución parcial debe ir unida al cargo que revierte, o su conciliación no cuadrará nunca.

Lo que de verdad pierde el pedido

En la práctica, el pago en línea falla por razones aburridas, no exóticas:

El importe es correcto y la moneda no. El proveedor rechaza y el cliente ve un error incomprensible.
La URL de retorno es un enlace de aplicación, no una dirección web. Algunos proveedores solo aceptan direcciones https normales y rechazan el resto — el pedido ni siquiera llega a crearse.
Nadie configuró el webhook. Los pagos salen bien, se cobra a los clientes, y nada en el restaurante se entera. Es el fallo más común, y es silencioso.
Nunca se cambiaron las claves de prueba por las reales. Todo funciona de maravilla y no llega ni un euro.

Ninguno de estos problemas es ingenioso. Son problemas de lista de comprobación, y precisamente por eso deberían estar en una — y por eso una prueba de conexión que llame de verdad al proveedor, en vez de limitarse a guardar sus claves, se gana su sitio en la pantalla de ajustes.

En resumen

Ofrezca las vías que sus clientes usan de verdad, fije precios por establecimiento en la moneda en que liquida, deje que el webhook — no la redirección — decida cuándo un pedido está pagado, y pruebe con claves reales antes de anunciar que la página está abierta. Lo demás es configuración.