Cobrar por uso significa calcular el importe a partir de una unidad de consumo: sesiones completadas, documentos generados, recursos utilizados o trabajo realizado. Para que funcione, el cliente debe entender qué se cuenta y tu sistema debe poder explicar cada unidad. Después interviene el cobro, con un importe y un periodo ya determinados.
Si tu servicio digital opera desde Andorra, prepara ambas partes antes de anunciar la modalidad: cómo mides el uso y cómo cobras el resultado. En AndorPay revisamos la conexión del pago con tu negocio; la medición y el cálculo necesitan un alcance propio. Un checkout que acepta un importe no equivale a un sistema completo de facturación por consumo.
Elige una unidad que el comprador reconozca
Una buena unidad se relaciona con el servicio que recibe el cliente. «Documento entregado» describe un resultado; «evento interno» describe tu tecnología. Si el comprador necesita conocer la arquitectura de la aplicación para entender su consumo, la explicación comercial todavía no está resuelta.
Piensa en qué momento se considera completada esa unidad. En un servicio de generación de documentos, ¿cuenta solicitarlo, terminarlo o descargarlo? Si una generación falla y el usuario la repite, ¿ha consumido una unidad o dos? Esa decisión debe estar clara antes de construir el contador.
Utiliza una sola definición en la oferta, la aplicación y el resumen de consumo. Cambiar de «tarea» a «crédito» sin explicar la relación dificulta comprobar el cobro. Puedes usar una unidad propia, pero debe tener un significado estable y comprensible para el cliente.
Separa consumo, cálculo y pago
El producto observa lo que ocurre. El registro de consumo conserva las unidades. Una regla convierte ese consumo en un importe. El documento correspondiente describe la venta y el sistema de pago intenta cobrarla. Aunque una herramienta pueda cubrir varias tareas, conviene identificar cada una.
| Capa | Pregunta que resuelve | Información necesaria |
|---|---|---|
| Servicio | ¿Qué ha recibido el cliente? | Resultado y momento de entrega |
| Medición | ¿Cuántas unidades cuentan? | Cliente, unidad e identificador |
| Cálculo | ¿Qué condiciones se aplican? | Regla vigente y periodo |
| Documento | ¿Qué operación se refleja? | Conceptos y datos aplicables |
| Cobro | ¿Se ha confirmado el importe? | Operación y estado del pago |
Esta separación ayuda cuando alguien pregunta por una diferencia. Si el contador muestra demasiadas unidades, repetir el pago no corrige el problema. Si el cálculo es correcto pero el cobro sigue pendiente, debes revisar la operación financiera. Un mismo panel puede mostrar ambas cosas, pero no son el mismo estado.
Decide cuándo se paga el consumo
Antes de utilizar el servicio
Un modelo de compra previa entrega una cantidad de uso o un saldo según las condiciones de la oferta. Debes explicar cómo se consume, qué ocurre al agotarse y si existe alguna condición temporal. El usuario necesita saber cuándo puede seguir utilizando el servicio y cuándo requiere otra compra.
Esta modalidad exige un registro de saldo coherente. Una acción fallida no debería descontar unidades si tu definición comercial solo cuenta resultados completados. Si dos solicitudes llegan a la vez, el sistema debe aplicar la regla sin permitir un consumo incompatible con el saldo disponible.
Al terminar un periodo
El modelo posterior suma el uso de un intervalo y calcula el importe al cierre. Define el inicio, el final y la zona horaria del periodo. Una actividad cerca del cambio de mes debe quedar asignada de forma consistente y poder localizarse después.
El comprador necesita visibilidad durante el periodo, especialmente si el uso puede variar mucho. Decide si habrá avisos, límites o una aprobación antes de seguir consumiendo. Esas son decisiones del servicio; no debes dar por hecho que el procesador de pagos conoce o controla tu contador.
Una base fija y una parte variable
Una oferta puede combinar acceso periódico con unidades adicionales. En ese caso explica qué está incluido, qué puede agotarse y qué acción produce un consumo extra. El cliente debe reconocer la frontera sin interpretar fórmulas internas.
Antes de elegir esta combinación, comprueba que tu aplicación puede mostrar el consumo incluido y el adicional por separado. Si no puede hacerlo, quizá una primera oferta más sencilla sea más fácil de operar. La guía de planes de suscripción ayuda a ordenar prestaciones y límites.
Diseña un registro que permita reconstruir el uso
Cada unidad facturable debería poder relacionarse con un cliente, una acción concreta, un momento y un resultado. Conserva un identificador estable de la acción para reconocerla si el mismo mensaje llega de nuevo. Reintentar la entrega de un evento no debería convertir un servicio en dos unidades cobrables.
La documentación de eventos de consumo de Airwallex ofrece un ejemplo técnico de identificadores para evitar duplicados. Es una referencia de diseño de ese proveedor, no una afirmación de disponibilidad comercial en Andorra ni una función atribuida a AndorPay.
También define cómo tratas eventos tardíos. Una tarea puede completarse antes del cierre y comunicarse después por una interrupción. Decide si se incorpora al periodo que le corresponde o entra en una revisión. Cambiar silenciosamente un total ya presentado dificulta explicar el importe al comprador.
Conserva la versión de la regla aplicada. Si cambias qué cuenta como unidad o qué incluye un plan, los periodos anteriores deben seguir siendo explicables con sus condiciones. El historial no debería reinterpretarse automáticamente con la configuración nueva.
Ejemplo: un servicio que prepara documentos
Imagina una aplicación que genera documentos a partir de información del usuario. Decides que una unidad corresponde a un documento completado y disponible. Una solicitud que termina con error no cuenta. Descargar de nuevo el mismo documento tampoco crea otra unidad.
El usuario puede consultar una lista de documentos terminados durante el periodo. El resumen agrupa ese uso y aplica las condiciones vigentes. Antes del cobro, el negocio puede identificar qué documentos forman el total y qué incidencias se excluyeron.
Si una tarea aparece dos veces porque se recibió el mismo evento, el identificador permite reconocer el duplicado. Si un documento se anuló por un error del servicio, el ajuste conserva el motivo y la referencia original. Así puedes explicar el cambio sin borrar la historia de lo sucedido.
Después de cerrar el cálculo se prepara el recorrido de pago compatible con la integración. El estado de ese cobro se vincula al periodo. El contador de documentos no debe pasar a «pagado» solo porque se haya generado el resumen; necesita el resultado económico correspondiente.
Prepara los límites y la conversación con el cliente
Una oferta por uso puede resultar difícil de anticipar si el cliente no ve cuánto lleva consumido. Presenta las unidades utilizadas en un lenguaje reconocible y aclara cuándo se actualizará el dato. Si existe retraso de registro, el contador no debe parecer una cifra definitiva en tiempo real.
Define qué sucede al alcanzar un límite: detener nuevas acciones, pedir una ampliación o seguir bajo una condición previamente acordada. La interfaz debe explicar esa decisión antes de que el usuario llegue al punto de bloqueo. Un límite oculto crea dudas tanto comerciales como de soporte.
Los avisos también necesitan contexto. «Has utilizado las sesiones incluidas en este periodo» es más útil que un código de error. Si puede contratar más uso, explica el siguiente paso y cuándo estará disponible. Si debe esperar al siguiente periodo, muestra la fecha aplicable.
Corrige diferencias antes de cobrar de nuevo
Cuando el cliente discrepa del consumo, localiza el periodo y las unidades que forman el cálculo. Comprueba si el problema está en un duplicado, una acción fallida contada indebidamente, una regla distinta o una expectativa mal explicada. El objetivo es poder reconstruir el importe con datos comprensibles.
Si el cálculo cambia antes del cobro, conserva el ajuste y prepara el nuevo total según el proceso acordado. Si ya hubo un pago, tratar la corrección requiere una gestión separada del registro de consumo. No supongas que modificar el contador devuelve dinero automáticamente.
Cuando el estado económico es ambiguo, revisa la operación existente antes de crear otra. La guía de renovaciones fallidas explica esta separación entre resultado de pago y siguiente acción. También se aplica a un cobro variable asociado a un periodo.
Comprueba qué puede hacer cada herramienta
Antes de ofrecer la modalidad, verifica quién mide el consumo, quién cierra el periodo, quién calcula y cómo llega el importe al pago. Una lista de funciones con la palabra «billing» no responde por sí sola esas preguntas.
Nuestra documentación de API describe los contratos disponibles. La posibilidad documentada de indicar un importe está sujeta a restricciones; no debe interpretarse como un motor abierto de precios por uso. Revisamos la compatibilidad del recorrido concreto antes de prometerlo para tu servicio.
Para hablar de esa integración, prepara un ejemplo de periodo con unidades, regla aplicada y resultado esperado, sin datos de clientes. Añade cuándo se cobraría y cómo se entrega el servicio. Esto permite evaluar el trabajo necesario con mucha más precisión que una petición genérica de «cobro flexible».
Pruebas necesarias antes del lanzamiento
Prueba una unidad completada, una fallida, un evento repetido y uno que llega tarde. Comprueba el cierre de periodo, los cambios de reglas y el caso sin consumo. El total esperado debe coincidir con el registro explicado al cliente.
Después valida el pago y su relación con ese periodo. Incluye resultado confirmado, rechazado y pendiente. Revisa qué ocurre con el acceso o el saldo en cada caso. El sistema debe poder explicar tanto el consumo como el cobro, incluso cuando no se completan al mismo tiempo.
Para decidir el alcance, cuéntanos qué unidad quieres cobrar y cómo la registras. En AndorPay revisamos el recorrido de pago y sus conexiones. Si todavía estás separando responsabilidades, la guía de pasarela de pagos y plataforma de gestión te ayuda a preparar esa conversación.
Preguntas frecuentes
¿Cobrar por uso es lo mismo que una suscripción?
La suscripción define una relación periódica; el uso define cómo se determina el importe o el derecho consumido. Pueden combinarse, pero necesitan reglas claras de calendario, medición y entrega.
¿Necesito guardar cada acción?
Necesitas conservar el detalle suficiente para justificar las unidades facturables, detectar duplicados y resolver diferencias. Qué acciones registras depende de tu definición de consumo; no todo evento técnico tiene que ser una unidad comercial.
¿Puedo cambiar de unidad después de lanzar?
Puedes plantear una nueva oferta, pero debes definir su fecha de aplicación y conservar la explicación de los periodos anteriores. Cambiar una regla no debería alterar silenciosamente el historial de consumo de tus clientes.