Pagos y facturación

Qué es

Pagos y facturación es todo lo necesario para cobrar dinero dentro de tu app: pago único, suscripciones recurrentes, facturas y un registro de cada transacción. En ybuild va integrado en la app y conectado a un procesador de pago real, para que los clientes te paguen directamente. Los planes, los precios y los recibos salen de tu descripción.

Por qué importa

Un sistema de negocio que no puede cobrar todavía no es un negocio: es una herramienta administrativa. Que la facturación viva dentro de la misma app en funcionamiento significa que los pagos están ligados a tus clientes y a sus datos, no acoplados por medio de una herramienta aparte que concilias a mano. Eso es lo que convierte el sistema en ingresos.

Cómo funciona en ybuild

Dile a ybuild qué cobras y cómo, y conecta el checkout, las suscripciones y la facturación dentro de la app en vivo. Todo está alojado en ybuild y se sirve en tu dominio, así que los clientes pagan en tu sitio y el dinero cae en tu cuenta conectada. Las transacciones quedan registradas en la propia base de datos de tu app, justo al lado del cliente al que pertenecen.

Qué ocurre en realidad cuando un cliente te paga

Cuando alguien toca 'Pagar' en tu app, pasan muchas cosas en el segundo previo a que aparezca el recibo, y la parte más importante es la que tu app, a propósito, nunca ve.

Los datos de la tarjeta se capturan en un campo que pertenece al procesador de pago, no al código de tu app. En cuanto se introducen, se envían directo al procesador y se cambian por un token: una referencia inofensiva, como el resguardo de un guardarropa, que hace de sustituto de la tarjeta real. Tu app guarda y trabaja con ese token; el número de tarjeta en bruto nunca toca tu servidor ni tu base de datos. Esa única decisión de diseño es la que te mantiene en la ruta de cumplimiento más corta que definen las redes de tarjetas (el nivel SAQ A), en lugar del mundo cargado de auditorías de manejar los datos de tarjeta tú mismo.

Con el token en mano, el procesador le pide al banco del cliente que autorice el cargo —una retención que verifica que la tarjeta es real y que hay fondos— y luego lo captura para mover el dinero de verdad. Para clientes en Europa y el Reino Unido, el banco puede activar un paso de Autenticación Reforzada de Cliente: un desafío 3D Secure, como un toque en la app bancaria o un código de un solo uso, que la normativa exige en muchos pagos sin tarjeta presente. Cuando se supera, el cargo se aprueba y el cliente nunca sale de tu dominio.

Aquí está la parte que la mayoría de los montajes caseros hace mal: la redirección de vuelta a tu página de éxito no es prueba de pago. La confirmación fiable es un webhook: un mensaje firmado que el procesador envía a tu backend diciendo que el cargo se realizó con éxito. ybuild conecta ese listener, verifica la firma y solo entonces escribe la transacción en la base de datos de tu app, al lado del cliente al que pertenece. Las entregas repetidas se hacen idempotentes, de modo que un webhook que llega dos veces no puede contar el pago dos veces. El resultado es un único registro de verdad: el cliente, el plan y cada cargo viviendo juntos en el mismo sistema en funcionamiento, no dispersos por un panel del procesador que concilias a mano.

Construir la facturación tú mismo vs. tenerla en ybuild

Vale la pena ser franco sobre el camino de hacerlo tú mismo, porque la facturación es una de las madrigueras más profundas del software.

Haciéndolo por tu cuenta, 'aceptar pagos' se expande en un proyecto propio: integrar el SDK del procesador, construir un checkout que maneje el flujo del desafío 3D Secure, levantar un endpoint de webhook con verificación de firma e idempotencia, y luego conciliar lo que dice el webhook con lo que cree tu base de datos. Las suscripciones convierten eso en una máquina de estados: pruebas que convierten, planes que suben y bajan a mitad de ciclo, cálculos de prorrateo, pausas, cancelaciones y reactivaciones, cada una con sus propios casos límite. Encima de eso está la mitad poco vistosa que nadie muestra en una demo: reintentar tarjetas fallidas, correos de cobranza, reembolsos, créditos prorrateados, gestión de contracargos y disputas, facturas con numeración secuencial, y el cálculo de impuestos sobre ventas o IVA que cambia según dónde esté el cliente. Cada una de esas cosas es un lugar por donde se fuga dinero o donde se cobra de más a un cliente.

En ybuild describes qué cobras y cómo —'un plan de 29 USD al mes con una prueba de 14 días y una opción anual', 'un pago único por cada pedido', 'facturas con vencimiento a 30 días'— y conecta el checkout, las suscripciones, la facturación y toda la plomería del webhook dentro de la app en funcionamiento. Se construye como un sistema full-stack alojado: la lógica de facturación, los registros de clientes y la base de datos viven juntos y salen en vivo en tu propio dominio. Los clientes pagan en tu sitio y el dinero cae en tu cuenta de procesador conectada.

La diferencia no es solo el esfuerzo inicial. Un stack de facturación hecho a mano es superficie operativa permanente: alguien es dueño del webhook que dejó de dispararse en silencio, de la renovación que cobró dos veces, de la regla de impuestos que cambió de la noche a la mañana. Como ybuild aloja la app y mantiene las piezas conectadas entre sí, cambiar un precio o añadir un plan es una frase, no una migración. Tú eres dueño de la parte que genera dinero —los clientes, los ingresos, el dominio— y la plomería de abajo es tarea de la plataforma.

Los tropiezos que muerden a la facturación en vivo, y qué significan para el negocio

Un puñado de casos límite atrapa a casi todos los equipos que operan facturación, y vale la pena nombrarlos porque un sistema en vivo se topa con todos ellos.

Las renovaciones fallidas son la silenciosa. Las tarjetas caducan, alcanzan límites o se rechazan por error, y los negocios de suscripción pierden alrededor del 9% de sus ingresos recurrentes mensuales por pagos fallidos, con tasas de fallo del sector entre el 5% y el 15%. La mayor parte es recuperable, pero solo si algo reintenta de forma inteligente y le escribe al cliente; sin cobranza, los ingresos simplemente se evaporan. Los rechazos por SCA son el primo europeo: un pago que habría pasado se bloquea porque nunca se ofreció un paso 3D Secure, así que el flujo del desafío hay que integrarlo, no acoplarlo. La idempotencia importa más de lo que suena: un tropiezo de red puede hacer que una solicitud de cargo llegue dos veces y, sin una salvaguarda, al cliente se le cobra dos veces y lo disputa. Los webhooks, no la redirección del navegador, son la fuente de verdad, así que un montaje que marca los pedidos como 'pagados' en la página de agradecimiento anotará ingresos fantasma en cuanto una tarjeta se rechace después de la redirección. Y el impuesto sigue la ubicación del cliente, no la tuya, lo que convierte en silencio un precio simple en una cuestión de cumplimiento en el momento en que vendes a través de fronteras.

Lo que obtienes por manejar todo eso correctamente es justo lo que hace que un sistema sea un negocio. Que la facturación viva dentro de la misma app significa que cada cargo está ligado al cliente y a sus datos: puedes ver quién está en qué plan, a quién le está fallando la tarjeta y cuánto vale cada cuenta, sin exportar un CSV y cuadrarlo contra un panel del procesador. El MRR, la rotación, la recuperación de pagos fallidos y el valor de por vida dejan de ser conjeturas de hoja de cálculo y pasan a ser propiedades del sistema en funcionamiento.

Esa es la diferencia entre una herramienta administrativa y una empresa. Una app creada a partir de un prompt que cobra en tu propio dominio, lo registra al lado del cliente y mantiene vivas las suscripciones a través del complicado tramo intermedio es un motor de ingresos que de verdad puedes operar: alojado en ybuild, en tu dirección, con el dinero cayendo en tu cuenta desde el primer día.

Preguntas frecuentes

¿Necesito mi propia cuenta de Stripe o de pagos para cobrar?

Conectas una cuenta de procesador de pago, y ahí es donde cae tu dinero: sigue siendo tuyo. ybuild construye el checkout, las suscripciones y la facturación dentro de tu app y los conecta a esa cuenta, para que los clientes te paguen directamente en tu propio dominio. No escribes la integración ni cuidas los webhooks; la plataforma los mantiene en marcha detrás de la app en vivo.

¿Es seguro cobrar con números de tarjeta en una app de ybuild?

Sí, porque tu app nunca toca el número de tarjeta en bruto. Los datos de la tarjeta se capturan en el campo seguro del propio procesador y se cambian por un token antes de llegar a tu código, así que los datos sensibles quedan fuera de tu servidor y fuera de tu base de datos. Eso mantiene tu app en la ruta de cumplimiento más corta de las redes de tarjetas (SAQ A), en lugar del nivel cargado de auditorías pensado para los comercios que almacenan datos de tarjeta ellos mismos.

¿Puedo gestionar suscripciones con pruebas gratuitas, mejoras de plan y cancelaciones?

Sí. Describe los planes —mensual y anual, una prueba gratuita, niveles entre los que los clientes pueden moverse— y ybuild construye la facturación recurrente, la conversión de la prueba, el prorrateo de los cambios a mitad de ciclo y la cancelación dentro de la app en vivo. El estado de la suscripción vive en tu propia base de datos, al lado del cliente, así que siempre sabes exactamente quién está en qué plan.

¿Qué pasa cuando la tarjeta de un cliente se rechaza en la renovación?

La app reintenta y da seguimiento en lugar de perder los ingresos en silencio. Las renovaciones fallidas hacen que los negocios de suscripción pierdan en torno al 9% de los ingresos recurrentes a nivel del sector, y la mayoría es recuperable con reintentos inteligentes y correos de cobranza, así que ybuild integra ese flujo de recuperación. Como la facturación está dentro de tu app, puedes ver exactamente qué cuentas están fallando y actuar sobre ellas.

¿Puede manejar facturas e impuestos sobre ventas?

Sí. ybuild construye la facturación —números de factura secuenciales, fechas de vencimiento, recibos— dentro de la app, y puede aplicar impuestos sobre ventas o IVA según dónde esté el cliente, ya que el impuesto sigue su ubicación y no la tuya. Todo queda registrado en la base de datos de tu app y se sirve en tu propio dominio, así que tus registros de facturación y tus registros de clientes son un solo sistema, no dos que tienes que conciliar.