Una venta no siempre termina con el mismo importe con el que empezó.
Un hotel puede autorizar un importe estimado y capturar otro. Un comercio electrónico puede enviar artículos en fechas diferentes y querer capturar por envío. Un servicio de movilidad puede conocer el precio final solo después del trayecto. Un marketplace puede necesitar dividir una operación en etapas. En algunos escenarios, el emisor puede aprobar solo una parte del importe solicitado.
Aquí surgen tres conceptos que parecen similares, pero representan problemas distintos: autorización parcial, captura parcial y múltiples capturas.
Confundir estas operaciones produce errores de saldo, preparación y entrega de pedidos, conciliación y experiencia. Una arquitectura robusta necesita saber exactamente qué importe se solicitó, cuál se autorizó, cuánto se ha capturado y cuánto se puede capturar todavía.
¿Qué es la autorización parcial?
La autorización parcial se produce cuando una operación solicita un importe determinado, pero el emisor aprueba solo una parte.
Imagina una compra de R$ 300 en un contexto que admita partial authorization. La credencial solo tiene R$ 220 disponibles y el emisor autoriza ese importe.
El comercio debe decidir entonces qué hacer con los R$ 80 restantes.
Puede solicitar otro medio de pago, cancelar la operación o seguir una política específica del negocio.
¿Es habitual la autorización parcial en cualquier checkout?
No.
La compatibilidad depende de la red de tarjetas, el emisor, el adquirente, el PSP, el producto y la configuración.
Una integración no debería asumir que cualquier autorización puede devolver un importe parcial.
Cuando se utiliza esta función, la aplicación necesita una experiencia de usuario y una máquina de estados preparadas para ello.
¿Qué diferencia hay entre autorización parcial y captura parcial?
En la autorización parcial, el importe aprobado por el emisor es inferior al solicitado.
En la captura parcial, existe una autorización por un importe determinado y el comercio decide capturar solo una parte.
Son decisiones que se toman en momentos distintos del ciclo y por actores diferentes.
¿Qué es la captura parcial?
La captura parcial consiste en capturar un importe inferior al total autorizado previamente, cuando el método y el proveedor admiten ese comportamiento.
Si se han autorizado R$ 1.000 y el importe final es R$ 840, el comercio puede capturar R$ 840 en vez de cobrar R$ 1.000 y devolver después R$ 160.
Esto reduce movimientos innecesarios y representa mejor el importe realmente adeudado.
¿Qué ocurre con el importe no capturado?
Depende del tipo de captura y del proveedor.
En algunos modelos de single partial capture, la parte no capturada se libera o se cancela después de la captura parcial.
En los modelos de multiple partial captures, el saldo restante sigue disponible para capturas posteriores según las reglas aplicables.
Esta diferencia debe quedar explícita en la integración.
¿Qué son las múltiples capturas?
Son varias operaciones de captura asociadas a una misma autorización o a un mismo contexto autorizado, cuando el proveedor y el esquema de pago lo permiten.
Un pedido de R$ 1.000 puede tener R$ 600 capturados cuando sale el primer envío y R$ 400 cuando se envía el segundo.
La autorización inicial sigue siendo la referencia financiera de las capturas.
¿Por qué utiliza el comercio electrónico múltiples capturas?
Porque la preparación y entrega de pedidos se puede dividir.
Si un pedido contiene tres artículos que se envían en momentos distintos, cobrar cada envío cuando sale realmente puede reflejar mejor el proceso comercial.
Esto también evita capturar el pago de un producto que aún no está disponible.
¿Pueden coexistir la autorización parcial y las múltiples capturas?
En teoría, un flujo complejo puede incluir ambas, pero su disponibilidad depende de las capacidades específicas del proveedor y del esquema de pago.
La arquitectura no debería asumir que siempre se pueden combinar.
Cada capacidad debe identificarse y tratarse de forma explícita.
¿Qué es una preautorización?
La preautorización es un tipo de autorización que se utiliza cuando el importe final puede cambiar o la captura se realizará más tarde.
Es habitual en hostelería, alquiler y movilidad.
El objetivo es obtener un compromiso inicial sin afirmar que ese sea necesariamente el importe final.
¿Es una preautorización lo mismo que una autorización ordinaria?
El concepto básico sigue siendo la autorización, pero algunos esquemas y proveedores distinguen tipos de autorización para permitir ajustes y capturas posteriores de forma adecuada.
La integración debe seguir la semántica del procesador.
No es seguro tratar cualquier autorización como ajustable indefinidamente.
¿Qué es un authorization adjustment?
Es la modificación del importe autorizado antes de la captura final, cuando el flujo lo admite.
Un hotel puede autorizar un importe estimado y después aumentarlo o reducirlo según el consumo y la estancia.
Este ajuste no equivale a realizar un nuevo cobro independiente.
¿Puedo capturar más de lo autorizado?
Normalmente no, salvo mediante un mecanismo específico de ajuste, reautorización u operación adicional permitido por el proveedor.
Intentar capturar por encima del saldo autorizado suele fallar.
La aplicación necesita conocer el remaining authorized amount.
¿Qué es el saldo autorizado restante?
Es la parte del importe autorizado que todavía no se ha capturado ni cancelado dentro de ese flujo.
Si se han autorizado R$ 1.000 y capturado R$ 600, pueden quedar R$ 400 para una captura posterior cuando se admite multiple partial capture.
Este saldo es distinto del saldo bancario del cliente.
¿Cómo se modelan los importes en el payment?
Guardar solo amount no es suficiente.
Resulta útil distinguir requested_amount, authorized_amount, captured_amount, refunded_amount y remaining_capturable_amount.
Los nombres pueden variar, pero los conceptos deben existir.
¿Por qué captured_amount no debe sustituir a amount?
Porque se pierde la intención original.
Si la compra solicitó R$ 1.000 y capturó R$ 840, ambos hechos son importantes.
La diferencia puede explicar una cancelación parcial, un ajuste o una entrega incompleta.
¿Cómo interactúa el reembolso con la captura parcial?
Un reembolso solo puede devolver un importe que realmente haya avanzado hasta el cobro según el flujo aplicable.
Si se han autorizado R$ 1.000 y solo se han capturado R$ 600, no tiene sentido tratar los R$ 400 no capturados como un reembolso.
Pertenecen al saldo no capturado de la autorización.
¿Son diferentes aquí la cancelación de la autorización y el reembolso?
Sí.
Cancelar un importe todavía no capturado libera o cierra el compromiso de autorización.
El reembolso devuelve un importe ya cobrado.
Mezclarlos genera confusión financiera.
¿Cómo utiliza la hostelería este modelo?
Al hacer el check-in, el hotel puede obtener una autorización estimada.
Durante la estancia, puede ajustar el importe según las reglas del proveedor.
En el checkout, captura el importe final adeudado y libera cualquier diferencia.
Este modelo evita tener que conocer el importe exacto de antemano.
¿Cómo lo utilizan las empresas de alquiler?
Las empresas de alquiler pueden autorizar un importe que incluya la tarifa diaria, el depósito y posibles extras.
Después capturan el coste final.
La operación debe respetar las reglas de autorización ampliada y de ajustes cuando correspondan.
¿Cómo lo utilizan los servicios de movilidad?
Un trayecto puede empezar sin que se conozca el precio final exacto.
La plataforma puede preautorizar una estimación y capturar después.
Si el importe cambia de forma significativa, puede ser necesario ajustar la autorización o tratar la diferencia según las capacidades del PSP.
¿Cómo utiliza un marketplace las múltiples capturas?
Un marketplace puede tener pedidos con distintos vendedores o envíos.
Capturar por evento de preparación y entrega puede alinear el cobro con lo que se ha entregado.
Pero el reparto financiero entre vendedores es otro problema y no debe confundirse con la captura parcial.
¿Es la captura parcial un split payment?
No.
La captura parcial define cuánto se cobrará de la autorización.
El split define cómo se distribuye el importe capturado entre los participantes.
Una operación puede utilizar ambas funciones, pero responden a preguntas distintas.
¿Son las múltiples capturas múltiples cobros?
Desde el punto de vista del ciclo de vida de la autorización, son capturas vinculadas al mismo contexto.
Para el consumidor, la presentación puede variar según el emisor y el esquema de pago.
La aplicación no debería modelarlas como payments independientes si el proveedor las trata como modificaciones de la misma autorización.
¿Cómo se concilian múltiples capturas?
Cada captura necesita una identidad propia.
El sistema debe conservar el importe, la marca temporal, la referencia externa y el vínculo con la autorización original.
La suma de las capturas no puede superar lo permitido.
En la liquidación, cada captura puede producir movimientos que deben conciliarse.
¿Cómo se identifica cada captura?
Utiliza una referencia interna única para la intención de captura y conserva la referencia del PSP que devuelve la operación.
Esto facilita los reintentos, los webhooks y la conciliación.
¿Debe ser idempotente la captura?
Sí.
Si una captura sufre un timeout, repetirla con una identidad nueva puede crear una segunda captura cuando se permiten múltiples capturas.
Cada intención de captura debe tener una clave estable.
¿Por qué aumentan las múltiples capturas el riesgo de duplicidad?
Porque el sistema acepta varias capturas legítimas.
Un proveedor no puede rechazar sin más una «segunda captura» por duplicada.
La plataforma necesita saber si la segunda operación es una nueva parte legítima o un reintento de la primera.
La idempotencia por capture_id resuelve esta ambigüedad.
¿Cómo funcionan los webhooks en este escenario?
Cada captura puede generar su propio evento.
Los eventos pueden llegar desordenados o reenviarse.
La aplicación debe actualizar la captura correcta y recalcular el agregado del payment sin hacer retroceder su estado.
¿Debe tener el payment un estado «partially_captured»?
Puede resultar útil.
Si existe un importe autorizado y solo se ha capturado una parte, un estado o atributo que lo represente ayuda a impedir operaciones incoherentes.
Otra opción es derivar el estado de los importes.
Lo importante es que la plataforma distinga entre captura nula, parcial y total.
¿Y «partially_authorized»?
Si la integración admite autorización parcial, también puede ser necesario representar que authorized_amount es inferior a requested_amount.
La experiencia de usuario debe actuar sobre la diferencia.
¿Qué se hace con el importe restante de una autorización parcial?
Depende del recorrido de compra.
La empresa puede pedir otro método para completar el total, reducir el pedido o cancelar la autorización parcial.
No debería dar por totalmente pagada una venta de R$ 300 si solo se han autorizado R$ 220, salvo que la regla comercial lo acepte expresamente.
¿Qué es split tender?
Es el uso de más de un medio de pago para completar una compra.
La autorización parcial puede formar parte de un recorrido de split tender: una credencial cubre una parte y otra cubre el resto.
Esto exige una máquina de estados del pedido capaz de sumar varios payments.
¿Cómo se evita liberar un pedido demasiado pronto?
Define la condición de preparación y entrega en función del importe capturado o confirmado necesario.
Si el pedido requiere R$ 300 y solo se han autorizado parcialmente R$ 220, todavía no está totalmente pagado.
El pedido debe seguir su cobertura financiera total.
¿Cómo se gestiona una captura superior al importe final?
Si es posible, ajusta o captura solo el importe adeudado antes del cobro.
Cobrar de más y reembolsar después crea más movimientos, una peor experiencia y más complejidad.
La captura parcial existe precisamente para evitar este patrón cuando se admite.
¿Y la propina?
Algunos sectores autorizan un importe base y añaden una propina o un ajuste posterior según reglas específicas.
Esto no es universal.
La integración debe utilizar los mecanismos previstos por el esquema y el proveedor.
¿Cómo se trata la moneda?
Normalmente, la captura debe respetar la moneda de la autorización.
Intentar capturar en una moneda distinta puede fallar.
La conversión de divisas debe tratarse en una capa propia, no como una simple modificación del capture amount.
¿Puede caducar la captura?
Las autorizaciones tienen plazos de validez.
El plazo exacto varía según el esquema de pago, el tipo de autorización y el proveedor.
La aplicación no debe codificar una regla universal de siete días ni ningún otro plazo único sin consultar el contrato específico.
¿Qué ocurre cuando caduca la autorización?
La captura puede dejar de ser posible y requerir una nueva autorización.
Por eso, una entrega tardía debe tener en cuenta la vigencia de la autorización.
Enviar un producto semanas después contando con una autorización antigua puede generar una pérdida.
¿Puedo reautorizar?
Algunos flujos permiten renovar o ajustar una autorización; otros exigen un nuevo intento.
La solución depende del proveedor.
El dominio debe tratar la reautorización como un evento explícito, no como un proceso invisible.
¿Cómo afectan las capturas parciales a la tasa de aprobación?
No cambian necesariamente la autorización inicial, pero pueden reducir fallos operativos cuando el importe final es inferior al estimado.
Por otra parte, las múltiples modificaciones pueden tener sus propias reglas y riesgos.
La optimización debe considerar el ciclo completo.
¿Cómo afectan las capturas parciales al cliente?
El cliente puede ver importes pendientes y cobrados en momentos distintos.
La comunicación clara es importante, especialmente en hostelería y alquiler.
La experiencia debe explicar que una autorización no es necesariamente el cargo final.
¿Por qué debe entender la diferencia el equipo de soporte?
Porque los clientes preguntan a menudo por qué vieron R$ 1.000 retenidos y R$ 840 cobrados.
Si atención al cliente llama «cobro» a todo, genera confusión.
El panel debería mostrar por separado la autorización, las capturas y las liberaciones.
¿Cómo representa un ledger la captura parcial?
La autorización puede existir fuera del ledger financiero o en una cuenta de reserva, según el modelo.
Cada captura genera sus propios movimientos por el importe realmente cobrado.
El total capturado es la suma de los asientos asociados.
¿Cómo se relacionan los múltiples reembolsos?
Una captura puede recibir reembolsos parciales posteriores.
La plataforma necesita saber qué parte del importe total capturado sigue siendo reembolsable.
En sistemas más detallados, el reembolso puede hacer referencia a una captura concreta.
¿Cómo se relaciona el chargeback?
Pueden surgir disputas sobre importes capturados.
Las múltiples capturas pueden generar referencias distintas que deben conservarse para la conciliación y las pruebas.
Esto refuerza la necesidad de una identidad por operación.
¿Cómo se modela una API de captura?
La API debería recibir el payment o la authorization de origen, el importe y una idempotency key.
La respuesta debe devolver un capture_id propio y un estado.
El recurso debe poder consultarse después.
¿Debe ser diferente capture_id de payment_id?
Sí, especialmente cuando se permiten múltiples capturas.
Un payment puede tener varias capture operations.
Utilizar solo payment_id dificulta distinguir los reintentos de las capturas nuevas.
¿Cómo se gestiona una solicitud de captura aceptada pero todavía no definitiva?
Modela un estado intermedio.
Una API puede aceptar la solicitud y confirmar el resultado después mediante un webhook.
«Request received» no debe tratarse automáticamente como dinero liquidado.
¿Puede fallar una captura después de ser aceptada?
Dependiendo del proveedor y del esquema de pago, sí.
Algunas plataformas documentan que una solicitud inicialmente aceptada todavía puede fallar más adelante.
La aplicación debe seguir los eventos asíncronos y no dar por finalizada la operación antes de tiempo.
¿Qué se hace cuando falla una captura?
Conserva la autorización y comprueba si todavía existe saldo capturable y si se permite reintentar.
No crees un nuevo cobro sin entender el estado.
La política depende del motivo del fallo.
¿Cómo se evita una captura excesiva?
Utiliza invariantes.
La suma de las capturas completadas y de las que están en estados que reservan importe no debe superar el límite autorizable según el proveedor.
La base de datos puede ayudar con bloqueos y transacciones para evitar una carrera entre dos capturas simultáneas.
¿Es posible una condición de carrera?
Sí.
Dos workers pueden intentar capturar R$ 300 cada uno de un saldo restante de R$ 400.
Si ambos leen el saldo antes de cualquier actualización, pueden enviar R$ 600 al PSP.
La aplicación necesita serializar las operaciones o reservar el importe de forma atómica.
¿Cómo se reserva el importe para una captura en curso?
Una opción es incluir las capturas pendientes en la fórmula de remaining_capturable_amount.
Así, el importe queda temporalmente indisponible para otra operación hasta que se resuelva la primera.
Si falla, se libera la reserva.
¿Cómo se gestiona un timeout de captura?
La captura pasa a un estado desconocido y el importe debe permanecer reservado hasta la conciliación.
Liberar el saldo inmediatamente y crear otra captura puede duplicarla.
¿Cómo afectan las múltiples capturas al Smart Routing?
En general, la captura debe seguir el contexto de la autorización original.
No es una nueva decisión arbitraria de enrutamiento entre adquirentes.
La autorización y la captura pertenecen a la misma relación de procesamiento.
¿Puedo autorizar en un PSP y capturar en otro?
No como continuación de la misma autorización ordinaria.
Cada PSP tiene su propia referencia y relación con el adquirente.
Cambiar de ruta suele significar un nuevo intento, no la captura de la autorización anterior.
¿Cómo afecta esto a la portabilidad?
Una autorización abierta crea una dependencia temporal de esa ruta.
Mientras quede importe capturable, las operaciones relacionadas deben utilizar el proveedor original.
Esto debe tenerse en cuenta en las arquitecturas multi-PSP.
¿Qué métricas conviene seguir?
Autorización total frente a parcial, importe autorizado, tasa de captura, captura parcial, fallo de captura, tiempo hasta la captura, saldo caducado y diferencias de importes.
En múltiples capturas, sigue el número medio de capturas por payment y la incidencia de capturas excesivas bloqueadas.
¿Cómo se prueba?
Prueba capturas nulas, parciales y totales, dos capturas concurrentes, timeout, reintento idempotente, autorización caducada, reembolso después de una captura parcial y eventos desordenados.
Prueba también un PSP que solo admita single partial capture.
¿Cómo se documentan las capacidades por proveedor?
Mantén una matriz explícita.
¿Qué métodos admiten captura manual? ¿Parcial? ¿Múltiple? ¿Ajustes de autorización? ¿Cuál es el plazo? ¿Hay reglas por red de tarjetas?
No disperses condiciones implícitas por el código.
¿Cómo se normaliza sin ocultar diferencias?
La plataforma puede ofrecer conceptos comunes como autorización, captura e importe restante.
Cuando un PSP no admite múltiples capturas, la capacidad debe devolver false y la API debe impedir la operación.
Una buena abstracción no promete una función inexistente.
¿Qué diferencia hay entre autorización parcial, captura parcial y múltiples capturas?
La autorización parcial se produce cuando el emisor aprueba menos del importe solicitado.
La captura parcial se produce cuando el comercio decide cobrar menos del importe autorizado.
Las múltiples capturas permiten dividir el importe autorizado en más de una operación de captura.
Son tres capacidades distintas.
Los importes variables exigen un dominio explícito
Cuando requested, authorized y captured pueden diferir, el sistema debe dejar de tratar amount como un único número.
La arquitectura debe conservar cada importe, cada operación y cada referencia.
Esto mejora la preparación y entrega de pedidos, el soporte, la conciliación, los reembolsos y la gestión del riesgo.
Lo que parece un matiz de API es, en realidad, un cambio importante en el modelo financiero del producto.