El pago que se aprobó a las once de la noche
Alguien paga a las ocho. El pago queda pendiente de revisión: no aprobado, no rechazado. La operación no se confirma y el lugar vuelve a estar disponible.
A las once de la noche el pago se aprueba. Nadie está mirando. El dinero entró, la persona cree que tiene su lugar reservado, y el sistema hace tres horas que lo dio por perdido. Para peor, a las nueve alguien más tomó ese mismo lugar y pagó sin problemas.
A la mañana siguiente hay dos personas con comprobante de pago para lo mismo. No fue un error de nadie: fue asumir que el resultado de un cobro se sabe en el momento en que la persona termina de pagar.
El resultado no llega cuando el cliente vuelve
Después de pagar, al cliente lo devuelven a tu sitio con un parámetro que dice cómo salió. Ese dato sirve para mostrarle un mensaje y para nada más: viaja por el navegador del cliente, se puede perder si cierra la pestaña antes de tiempo, y llega antes de que el pago esté realmente resuelto.
La fuente confiable es la notificación que el procesador manda a tu servidor cuando el estado cambia. Es la única que llega aunque el cliente haya cerrado todo, y la única que vuelve a llegar cuando el estado cambia de nuevo horas después.
El detalle que hay que resolver el primer día: esa notificación avisa que algo pasó, pero no hay que creerle el contenido. Lo correcto es tomar el identificador del pago y consultar su estado actual contra la API. Sin eso, cualquiera que descubra la dirección de tu endpoint puede avisarte que un pago se aprobó.
La misma notificación va a llegar varias veces
Los sistemas de notificación reintentan cuando no reciben una confirmación clara, y a veces mandan el mismo aviso más de una vez aunque todo haya salido bien. Si cada llegada dispara la acción completa, un pago termina generando dos reservas, dos mails y dos asientos contables.
La forma de evitarlo es guardar el identificador del pago junto con el estado que ya se procesó. Si llega un aviso con un estado que ya se aplicó, se responde que está todo bien y no se hace nada más. Si llega con un estado nuevo, se aplica la transición.
Además conviene que la respuesta al aviso sea inmediata y que el trabajo pesado quede para después. Un endpoint que tarda en contestar porque está mandando mails va a recibir reintentos, y ahí es donde aparece la duplicación.
Los estados que llegan tarde y los que vuelven atrás
Un pago pendiente que se aprueba dos horas después, un rechazado que después entra por otro medio, una devolución total o parcial semanas más tarde, un contracargo que aparece cuando ya nadie se acuerda de la operación. Todos existen y todos tienen que tener un camino previsto.
La regla que ordena todo esto es que el estado del cobro y el estado de la operación son dos cosas separadas que hay que poder ver enfrentadas. Una reserva confirmada con un pago devuelto es una contradicción que el sistema tiene que poder mostrar, no una situación imposible que hay que evitar por diseño.
Cuando esa contradicción aparece, casi nunca se puede resolver automáticamente: alguien tiene que decidir. Lo que sí puede hacer el sistema es garantizar que aparezca en una lista para revisar, en lugar de quedar enterrada hasta que el cliente reclama.
Lo que cobra el procesador no es tu ingreso
Entre lo que paga el cliente y lo que se acredita en tu cuenta hay una comisión, y a veces un plazo. Si el sistema registra el monto que pagó el cliente como si fuera lo que entró, el número que ves todos los días está inflado.
Guardar los dos montos por separado —lo cobrado y lo neto acreditado— y registrar la fecha de acreditación además de la del pago es lo que después permite conciliar contra el resumen del procesador sin tener que rehacer la cuenta.
Preguntas frecuentes
¿Puedo cobrar en cuotas?
Sí, con las opciones que tengas habilitadas en tu cuenta. Desde el sistema se define qué se ofrece en cada caso y quién absorbe el costo financiero, si vos o el cliente.
¿Qué pasa si el cliente cierra la ventana antes de volver?
No pasa nada malo. El resultado no depende de que el cliente vuelva a tu sitio: llega igual a tu servidor por la notificación, así que la operación se resuelve sola aunque él no vea la pantalla final.
¿Cómo hago devoluciones?
Se pueden disparar desde el sistema, totales o parciales. Lo importante es que la devolución quede vinculada al cobro original y que el estado de la operación se actualice en consecuencia, para que no queden confirmadas cosas que ya se reembolsaron.
¿Se puede probar sin mover dinero real?
Sí, con credenciales de prueba y usuarios de prueba. Todo el circuito —incluida la notificación de cambio de estado— se recorre completo antes de tocar una cuenta productiva.
¿Y si quiero usar otro medio de cobro además?
Conviene que el sistema tenga una noción propia de cobro y que cada pasarela sea una forma de completarlo. Así agregar otra más adelante no obliga a rehacer la lógica de la operación, sólo a sumar un camino de pago.
¿Cobran comisión por esto?
No. La única comisión es la del procesador y va directo a ellos. Nosotros construimos la integración una vez y no participamos de tus cobros.
Seguir leyendo
Sistema de reservas online para canchas
Que tus clientes reserven y paguen sin llamarte. Grilla de canchas, señas, cancelaciones y confirmación automática.
Caja y cierre diario en un sistema de gestión
Que el cierre del día sea un botón y no una tarde con la calculadora. Movimientos, medios de pago y diferencias.
Sistema de cuotas y cobranzas para desarrollos
Unidades, planes de pago, saldos y quién debe qué. Sin planillas compartidas que actualiza una sola persona.
Sistema de turnos y gestión para centros de salud
Turnos online, fichas de pacientes, profesionales y caja en una sola pantalla. Para consultorios y centros de salud.