Cuando alguien nos pregunta qué pasarela de pago conviene, la respuesta honesta es: casi cualquiera. Todas cobran, todas acreditan, todas tienen un panel.
Lo que se paga caro después no es esa decisión. Son estas otras, que suelen tomarse sin pensar mucho y son bastante difíciles de revertir.
El pago no es un evento, es una máquina de estados
El error más común es tratar el pago como algo que pasa una vez: el cliente paga y listo. En la práctica un pago atraviesa varios estados —pendiente, aprobado, rechazado, en revisión, devuelto, contracargo— y puede moverse entre ellos días después.
Si el sistema sólo entiende "pagado / no pagado", cada estado intermedio se convierte en una llamada telefónica. La transferencia que acredita a las 48 horas, el pago en efectivo que el cliente hace recién el viernes, la devolución parcial: todo eso existe y va a pasar.
Modelar los estados desde el principio no agrega casi trabajo. Agregarlos después, cuando ya hay miles de órdenes con un booleano, es una migración.
Nunca confíes en el navegador para confirmar un pago
Este es el que más veces vimos mal implementado, y es un problema de seguridad, no de prolijidad.
El flujo intuitivo es: el cliente paga, la pasarela lo redirige de vuelta a tu sitio con un "listo", y tu sistema marca la orden como pagada. El problema es que esa vuelta pasa por el navegador del cliente, y cualquiera puede construirla a mano. Estás dejando que el comprador te avise si pagó.
La confirmación tiene que venir del webhook: un llamado servidor a servidor de la pasarela, verificado con su firma. La redirección del navegador sirve para mostrarle algo lindo al cliente, nada más.
Y el webhook trae su propia letra chica: puede llegar antes que el redirect, puede llegar duplicado, y puede llegar dos veces con estados distintos. Por eso tiene que ser idempotente —procesar el mismo aviso dos veces no puede cobrar dos veces— y hay que guardar el evento crudo, que es lo único que te salva cuando hay que auditar qué pasó.
Los montos no van en float
Parece un detalle de purista hasta que aparece una orden de $10.000 que sumó $9.999,99.
Los números decimales del punto flotante no representan exactamente valores como 0,1. Las diferencias son ínfimas por operación y se acumulan. Se guardan en enteros —centavos— o en un decimal exacto. Nunca en float.
Es una línea de código el primer día y un dolor de cabeza contable al año.
La conciliación es parte del proyecto
Todo sitio que cobra necesita, tarde o temprano, responder: ¿lo que dice mi sistema coincide con lo que dice la pasarela y con lo que entró al banco?
Si esa pregunta no se puede contestar sola, alguien la va a contestar a mano con un Excel todos los meses. Y va a encontrar diferencias, porque siempre las hay: comisiones, retenciones, cuotas, devoluciones.
No hace falta construir un sistema contable. Alcanza con guardar el ID de la transacción de la pasarela junto a cada orden y poder listar diferencias. Es poco trabajo si se piensa desde el principio.
Lo específico de acá
Argentina tiene particularidades que no aparecen en la documentación en inglés:
- Cuotas. El costo financiero puede estar a cargo del comercio o del cliente, y eso cambia el precio que se muestra. Es una decisión de negocio que impacta en el código.
- Retenciones e impuestos. Lo que acredita no es lo que se cobró. Si el sistema asume que sí, la conciliación no va a cerrar nunca.
- Múltiples medios conviviendo. Tarjeta, transferencia, billetera y a veces efectivo. Cada uno con su tiempo de acreditación distinto.
Ese último punto es el que más impacta en la operación: si el sistema no sabe que una transferencia tarda, alguien va a tener que revisar el home banking a mano para liberar pedidos.
El resumen
Elegí la pasarela por soporte y por costo, que es donde realmente se diferencian. Pero diseñá el pago como una máquina de estados, confiá sólo en el webhook, guardá los montos en enteros y dejá la conciliación resuelta desde el día uno.
Eso es lo que hace la diferencia entre un checkout que funciona y uno que funciona y además te deja dormir.
En nuestros casos de e-commerce mostramos proyectos donde esto está resuelto. Si estás por encarar un checkout, escribinos.
