Si vas a cobrar desde una aplicación, quien compra necesita saber qué obtiene, cuándo puede usarlo y qué ocurre si un pago falla o cancela. El botón de pago es solo una parte visible de la experiencia: también cuentan la confirmación, la renovación y la atención de incidencias.
Puedes explicar el producto y la experiencia que quieres ofrecer, aunque no conozcas los estados de una pasarela. Ricardo puede ayudarte a definir el ciclo y construir la integración, o partir de requisitos que ya tengas listos. Estas decisiones deben quedar claras en la propuesta.
Separa producto precio y acceso
Son tres acuerdos relacionados:
- Producto: qué capacidad o servicio se entrega.
- Precio: cuánto y cómo se cobra.
- Acceso: qué puede utilizar la persona y durante qué periodo.
Una aplicación puede recibir un pago único, ofrecer suscripción o utilizar otro modelo. La arquitectura no decide cuál es rentable ni qué precio debería tener.
En este artículo usaremos Cuaderno de equipos, un ejemplo ficticio con pagos simulados. Sus planes Base y Equipo permiten explorar límites y cambios sin introducir tarifas ni tarjetas reales.
El recorrido que debe cubrir el encargo
La propuesta debería explicar qué ocurre en estos momentos; no hace falta que prepares una política completa antes de conversar:
| Momento | Decisión necesaria |
|---|---|
| Alta | Quién contrata, qué se crea y qué falta para obtener acceso |
| Confirmación | Qué hecho acredita el pago y cómo se relaciona con la cuenta |
| Uso | Qué funciones y límites concede el plan |
| Renovación | Qué periodo se amplía y cuándo |
| Fallo | Qué aviso, posibilidad de recuperación y acceso se mantienen |
| Cambio de plan | Cuándo se aplica y qué sucede con el uso existente |
| Cancelación | Si es inmediata o al final del periodo y qué conserva la cuenta |
| Reembolso | Quién lo decide y cómo afecta al pago y al acceso |
| Vuelta al servicio | Si se reactiva una relación o se crea una nueva |
| Salida | Cómo se exporta o se trata la información conservada |
No hace falta resolverlo con el vocabulario del proveedor. Primero se acuerda contigo el comportamiento del producto; después el profesional lo relaciona con los estados y eventos de la integración elegida.
Un caso que permite ver las decisiones
En el Cuaderno, el plan Base admite tres proyectos activos y Equipo diez. Son límites didácticos, no precios de una oferta.
Una organización entra con Base, crea proyectos, cambia a Equipo y después reduce su plan. El recorrido obliga a decidir qué ocurre si conserva más de tres proyectos.
En el ejemplo se mantiene lectura y exportación y se limita la creación de nuevos proyectos hasta volver al límite. No se eliminan registros automáticamente. Esa regla protege la continuidad del ejercicio y permite explicar el siguiente paso: archivar, revisar el plan o exportar.
Otra aplicación puede necesitar una política distinta. Lo importante es que la propuesta la describa y las pruebas comprueben esa decisión, en vez de dejarla a un mensaje genérico de error.
Qué acceso ve la persona en cada momento
Un pago puede estar pendiente mientras la aplicación ya ha creado una cuenta. También puede fallar una renovación de una cuenta que antes tenía acceso. Esos casos no son iguales.
El siguiente mapa utiliza nombres de producto para describir el comportamiento del ejemplo:
| Situación | Estado de acceso del ejercicio | Qué ve la persona |
|---|---|---|
| Alta sin confirmar | Pendiente | Qué falta para completar el acceso |
| Confirmación válida | Activo | Plan y capacidades disponibles |
| Renovación con incidencia | Según política de recuperación definida | Aviso, acción necesaria y fecha/condición relevante |
| Cancelación solicitada al final del periodo | Activo hasta el fin acordado | Cuándo termina y qué seguirá disponible |
| Fin de acceso | Consulta/exportación según alcance | Límites y opciones de continuidad |
| Nueva contratación o vuelta permitida | Acceso recalculado | Plan, periodo y datos conservados |
Esta tabla define el comportamiento deseado del ejemplo, no una política universal. El estado técnico del proveedor se relaciona después con el acceso del producto; una casilla “pagado” no explica todos los casos.
Comprueba más que un pago correcto
El equipo puede preparar este guion para que revises qué sucede en cada situación:
- Crear un alta que todavía necesita confirmación.
- Confirmar una operación y comprobar el acceso de la cuenta correcta.
- Repetir la notificación y comprobar que no duplica el efecto.
- Simular un pago fallido y revisar mensaje, recuperación y acceso.
- Solicitar cancelación al final del periodo y comprobar ambos momentos.
- Reducir plan con uso por encima del límite sin borrar datos.
- Volver al servicio siguiendo la regla acordada.
- Exportar la información que la cuenta debe conservar.
El demostrador SaaS permite explorar estos cambios en simulación. Para cobrar de verdad hacen falta la integración y sus pruebas en el entorno correspondiente, además de las decisiones de operación.
Incluye a quien administra y atiende
La persona que paga puede ser distinta de quien utiliza la aplicación. Define quién puede consultar facturación, cambiar plan, cancelar o atender una incidencia.
Un operador también necesita información suficiente para investigar: qué operación se esperaba, qué notificación llegó y qué estado mantiene el producto. Evita utilizar correos sueltos o capturas como único registro de una decisión que afecta al acceso.
La matriz de usuarios, roles y datos ayuda a separar esas responsabilidades. El acceso a facturación no tiene por qué conceder edición de todos los contenidos de una organización.
Si la aplicación se distribuye en una tienda
Una integración de pagos web no define por sí sola cómo se puede cobrar dentro de una app distribuida por Apple o Google. El tipo de producto, región y reglas de la tienda pueden cambiar el alcance.
Antes de cerrar una propuesta móvil, revisa las App Review Guidelines de Apple y la política de pagos de Google Play, consultadas el 10/09/2026. No basta con presupuestar una pasarela sin comprobar ese contexto.
Qué debe quedar claro en una propuesta
Además de “integración de pagos”, pide que se describan:
- Producto/plan, límites y relación con el acceso.
- Alta, confirmación, renovación y fallos.
- Cambios, cancelación, reembolso y vuelta al servicio.
- Roles y administración.
- Validación, duplicados y conciliación.
- Pruebas, soporte, costes de proveedor y responsabilidades.
- Continuidad y tratamiento de datos al salir.
Puedes incorporarlo al mapa de alcance de producto si te ayuda a comparar el encargo; no necesitas completarlo antes de pedir una propuesta. Si la pregunta anterior es si tu servicio debería convertirse en un producto de suscripción, empieza por la unidad de valor y la operación de un SaaS.
Así podrás revisar el ciclo que estás contratando, no solo la pantalla donde se introduce el pago. Si tienes una idea de producto o requisitos preparados, puedes comentar el proyecto con Ricardo.
Detalle de integración para revisar con el profesional
En una integración con Stripe, por ejemplo, la documentación distingue estados de suscripción como active, incomplete, past_due, unpaid o canceled. Active no significa que todas las facturas históricas estén pagadas, y canceled es un estado terminal de esa suscripción. La vuelta al producto puede necesitar crear otra. Ciclo de suscripciones de Stripe, consultado el 10/09/2026.
La página a la que vuelve el navegador después del pago sirve para comunicar. La aplicación necesita comprobar el resultado de la operación y asociarlo a la cuenta correcta. En Stripe, invoice.paid informa de una factura pagada; la documentación explica cómo utilizarlo junto al estado activo de suscripción para conceder acceso. Crear una suscripción o una factura no equivale a confirmar su pago. Eventos de suscripciones, consultados el 10/09/2026.
Al concretar una integración, el profesional debe incluir validación del origen, relación entre cuenta, pago y suscripción, repetición de eventos y recuperación ante una notificación perdida. Si un evento llega dos veces, no debería duplicar periodos o efectos. Si falta una notificación, debe existir una forma de conciliar el estado. Son comprobaciones de implementación, no tareas previas para quien encarga la aplicación.