Cuando un cliente ve el mensaje «pago aprobado», es natural pensar que todo el proceso financiero ha terminado en ese instante. Sin embargo, en la infraestructura de pagos, la aprobación puede representar solo una etapa de un ciclo más amplio.
Una transacción puede haberse creado, enviado a procesar, autorizado, capturado, confirmado como pagada, cancelado, reembolsado o impugnado. Algunos de estos cambios se producen durante la solicitud inicial. Otros llegan segundos, horas o días después.
Entender este ciclo de vida no es solo una cuestión de nomenclatura. El modelo adoptado determina cuándo se puede liberar un pedido, cuándo confirmar una reserva, cuándo todavía es posible cancelar una autorización, cuándo hace falta iniciar un reembolso y cómo debe reaccionar el sistema ante timeouts, webhooks tardíos y respuestas contradictorias.
Por tanto, una integración de pagos robusta no debería preguntar únicamente si el pago «ha salido bien». La pregunta más útil es: ¿en qué estado financiero se encuentra esta transacción ahora, qué hechos conocemos y qué transiciones siguen siendo posibles?
¿Qué es el ciclo de vida de una transacción de pago?
El ciclo de vida de un pago es la secuencia de estados y operaciones por la que pasa una intención de cobro, desde su creación hasta un resultado financiero final o una situación que requiere tratamiento posterior.
En un flujo de tarjeta con autorización y captura separadas, por ejemplo, podemos pensar conceptualmente en creación, procesamiento, autorización y captura. Después de la captura todavía pueden producirse una confirmación asíncrona, la liquidación, un reembolso, una disputa o un contracargo.
No se trata de un vocabulario universal de API. Distintos PSP, adquirentes, redes y plataformas utilizan objetos, nombres y estados diferentes. Incluso dentro de una misma plataforma, distintos métodos de pago pueden seguir recorridos diferentes.
Lo que importa desde el punto de vista arquitectónico son las transiciones de negocio que representan esos estados. Una autorización no es lo mismo que una captura. Una captura no es lo mismo que una liquidación. Cancelar una autorización antes de la captura no es necesariamente la misma operación que devolver fondos después del cobro.
Esta separación parece semántica hasta que llega el primer incidente en producción.
¿Qué significa autorizar un pago?
La autorización es la etapa en la que la infraestructura comprueba si un intento de pago puede continuar de acuerdo con las reglas del emisor, la red, el adquirente y los demás participantes implicados.
En tarjetas, una autorización aprobada normalmente indica que el emisor ha aceptado la operación y que existe un compromiso financiero asociado a ese importe. En muchos flujos, esto implica una retención temporal de crédito disponible o saldo, pero no significa necesariamente que el cobro haya finalizado para el comercio.
Cuando la autorización y la captura están separadas, existe un intervalo entre «la operación se ha autorizado» y «ahora queremos completar el cobro». Este diseño resulta útil cuando la confirmación comercial todavía depende de algún acontecimiento posterior.
Los hoteles pueden autorizar antes de la salida. Las empresas de alquiler de coches pueden necesitar retener un importe antes de conocer el coste final. Los marketplaces pueden esperar a confirmar las existencias o el envío. Las operaciones de preventa pueden querer capturar solo cuando el pedido esté listo para avanzar.
La idea principal es que la autorización decide si se puede continuar. No debería confundirse automáticamente con el final del ciclo financiero.
¿Una autorización aprobada significa que la venta ha finalizado?
No necesariamente.
Este es uno de los errores de modelado más habituales. Si la operación utiliza captura automática, la autorización y la captura pueden producirse tan cerca en el tiempo que parecen una única acción para la aplicación y el usuario.
Sin embargo, cuando hay captura manual, la diferencia queda explícita. El sistema puede saber que la transacción se ha autorizado, pero todavía debe decidir si la captura.
Si el comercio entrega definitivamente un producto solo porque se ha obtenido una autorización, pero la captura nunca se realiza, el estado comercial del pedido puede dejar de coincidir con el estado financiero del pago.
Por eso, los sistemas maduros suelen separar al menos tres conceptos: el pedido del cliente, la intención de pago y el estado del intento utilizado para ejecutar esa intención.
Mezclarlo todo en un único campo booleano, como «pagado = sí o no», funciona mientras el flujo es sencillo. Cuando aparecen la captura manual, varios PSP, reintentos, webhooks y reembolsos, el modelo empieza a perder información importante.
¿Qué es la captura?
La captura es la operación que confirma que un importe autorizado previamente debe avanzar hacia el cobro conforme al flujo de ese proveedor y método de pago.
Conceptualmente, la autorización responde a algo parecido a «¿puede continuar esta operación?». La captura responde a «queremos completar efectivamente el cobro autorizado».
En muchas integraciones, la captura es automática. La aplicación envía el pago y el proveedor ejecuta la autorización y la captura como partes próximas del mismo flujo.
En otras, la captura es manual. Esto permite al comercio esperar a que se produzca un acontecimiento de negocio antes de completar el cobro.
También puede haber captura parcial, según las capacidades del proveedor. Imagina una reserva autorizada por R$ 1.000 cuyo importe final es R$ 840. Si el flujo permite la captura parcial, el comercio puede cobrar solo el importe debido, en lugar de cobrar el total y reembolsar la diferencia.
Sin embargo, no debe darse por hecho que este comportamiento es idéntico en todas las integraciones. Algunos proveedores admiten la captura parcial, otros tienen reglas específicas y otros tratan el importe restante de forma diferente.
Por eso, una capa de pagos no debería fingir que todos los procesadores funcionan exactamente igual.
¿La captura es lo mismo que la liquidación?
No.
La captura y la liquidación son etapas relacionadas, pero no son sinónimos.
Capturar significa confirmar que el importe autorizado debe avanzar como cobro. La liquidación representa una etapa financiera posterior, en la que los participantes del ecosistema procesan el movimiento de fondos conforme a las reglas, los plazos y los esquemas del método de pago.
Desde la perspectiva del usuario, estas etapas pueden parecer una sola. Para la conciliación y la operativa financiera, no lo son.
Una empresa puede tener un pago correctamente capturado en su sistema transaccional y aun así necesitar confirmar después que el movimiento financiero correspondiente apareció como se esperaba en la liquidación.
Esta diferencia ayuda a entender por qué el «estado del pago» y el «estado del dinero» no deberían tratarse como conceptos absolutamente idénticos.
¿Qué significa cancelar una transacción?
La respuesta depende del momento del ciclo de vida.
Cuando una autorización todavía no se ha capturado, cancelar normalmente significa interrumpirla antes de completar el cobro. Conceptualmente, el sistema desiste de una operación que todavía no debería avanzar financieramente.
Después de la captura, el problema cambia. Ya existe un cobro completado o en una etapa posterior, y devolver los fondos pasa a ser un flujo de reembolso, no simplemente la cancelación de aquella autorización inicial.
Esta frontera es importante porque dos acciones que pueden parecer iguales al usuario final representan operaciones diferentes para la infraestructura.
El usuario puede decir «quiero cancelar la compra». El sistema necesita averiguar el estado financiero actual para decidir la acción correcta.
Si la autorización sigue abierta, la acción puede ser cancelarla o anularla. Si el cobro ya se ha capturado, puede ser necesario iniciar un reembolso. Si el resultado sigue siendo desconocido por un timeout, cualquier acción precipitada puede aumentar el riesgo de duplicidad o incoherencia.
¿La cancelación y el «estorno» son lo mismo?
Depende del vocabulario utilizado.
En el uso cotidiano brasileño, «estorno» puede referirse a varias situaciones: una autorización que ha desaparecido, una compra cancelada, un reembolso o incluso una reversión específica del adquirente.
Para producto y atención al cliente, ese término genérico puede bastar. Para una máquina de estados de pagos, no.
Una arquitectura robusta debe convertir términos ambiguos en operaciones precisas. La pregunta deja de ser «¿se ha hecho un estorno del pago?» y pasa a ser «¿se canceló la autorización antes de la captura, se reembolsó el cobro capturado o se produjo otro tipo de reversión?».
Esta precisión mejora el código, el soporte, la observabilidad y la conciliación.
También ayuda a evitar que dos equipos utilicen la misma palabra para operaciones financieras distintas y creen integraciones incompatibles entre sí.
¿Qué es un reembolso o refund?
El reembolso es una operación que se inicia cuando existe un cobro elegible para devolver total o parcialmente su importe al pagador.
A diferencia de la cancelación de una autorización todavía no capturada, aquí el sistema trata con una transacción que ya ha avanzado en el ciclo financiero.
El reembolso también tiene su propio ciclo de vida. Solicitar un refund no significa necesariamente que todo el proceso termine en ese mismo instante.
La operación puede aceptarse para su procesamiento y completarse de forma asíncrona. Puede haber un reembolso parcial. Puede producirse un fallo. Puede ser necesario recibir un webhook o consultar posteriormente el estado de la operación.
Por tanto, la aplicación no debería cambiar inmediatamente el estado local a «reembolsado» solo porque ha enviado una solicitud, salvo que el contrato del proveedor garantice que esa respuesta ya representa el resultado final.
El estado local debe representar lo que el sistema sabe realmente, no lo que espera que ocurra.
¿Un reembolso parcial cambia el estado del pago?
Puede cambiarlo, y esta es otra razón para evitar los modelos booleanos.
Imagina una compra de R$ 1.000. El cliente devuelve un artículo y recibe R$ 200. El cobro no está intacto, pero tampoco se ha reembolsado por completo.
Si el sistema solo conoce «pagado» y «reembolsado», debe elegir una representación incompleta.
Los modelos financieros más ricos pueden representar que el pago se completó y después recibió una devolución parcial. La implementación puede utilizar un estado específico, mantener los reembolsos como entidades separadas o combinar ambas opciones.
El principio importa más que el nombre: el importe capturado, el importe ya devuelto y el importe todavía disponible para devolución son datos diferentes.
Esta distinción también facilita la conciliación, la atención al cliente y la prevención de reembolsos superiores al importe realmente elegible.
¿Por qué no bastan pagado, cancelado y reembolsado?
Porque los sistemas de pagos también necesitan representar lo que todavía no ha finalizado.
Una solicitud puede estar pendiente. Una autorización puede haberse aprobado, pero no haberse capturado aún. Una captura puede estar en procesamiento. Un reembolso puede haberse solicitado, pero no confirmado. Una disputa puede comenzar mucho después de que un cobro pareciera finalizado.
Un intento también puede quedar temporalmente en estado desconocido porque el proveedor procesó la solicitud, pero la aplicación perdió la respuesta.
Modelar solo estados finales obliga al sistema a adivinar.
Modelar estados intermedios permite esperar, conciliar y reaccionar a la siguiente evidencia.
En pagos, «todavía no lo sé» puede ser un estado operativo mucho más seguro que «ha fallado».
¿Qué ocurre cuando hay un timeout?
Un timeout es una de las mejores pruebas para saber si el modelo de estados de una plataforma es realmente robusto.
Imagina que la aplicación envía una autorización. El PSP recibe la solicitud. El adquirente la procesa. La autorización se aprueba. Pero la conexión entre el PSP y la aplicación se interrumpe antes de que llegue la respuesta.
Desde el punto de vista financiero, la autorización puede existir. Desde el de la aplicación, se ha producido un timeout.
Si el sistema traduce automáticamente el timeout como pago rechazado, estará afirmando algo que no sabe.
Si envía inmediatamente otro cobro, podría crear una segunda autorización o un segundo efecto financiero.
El problema no consiste solo en reintentar. Es una cuestión de estado: ¿qué sabemos realmente sobre la transacción en ese instante?
Una arquitectura más segura conserva la ambigüedad hasta resolverla mediante los mecanismos disponibles, como la consulta de estado, la idempotencia, un webhook, la conciliación o una combinación de ellos.
¿Por qué forman los webhooks parte del ciclo de vida?
Porque el ciclo de un pago no cabe necesariamente en una única conexión HTTP.
Algunos cambios se producen después de la respuesta original. La captura, el reembolso, el análisis, la confirmación de métodos asíncronos, las disputas y otros eventos pueden generar actualizaciones posteriores.
Los webhooks permiten que la aplicación reciba esos cambios sin consultar continuamente al proveedor.
Pero esto introduce otro reto: los eventos pueden llegar tarde, repetidos o fuera de orden.
Recibir un webhook después de otro no significa que represente un estado más reciente. Un evento antiguo puede reenviarse mediante un reintento y llegar después de una actualización más nueva.
Por eso, el orden de llegada no debe confundirse con el orden de negocio.
La aplicación debe comprobar si la transición recibida tiene sentido desde el estado actual y, cuando sea necesario, consultar la fuente de verdad antes de hacer retroceder un objeto financiero.
¿Qué es una transición de estado válida?
Una transición válida es un cambio que tiene sentido a partir del estado actual y de las reglas de esa operación.
Un cobro pendiente de captura puede aceptar determinadas acciones. Después de la captura, cambia el conjunto de operaciones posibles. Tras un reembolso completo, probablemente no tenga sentido intentar capturar de nuevo esa misma autorización.
El modelo de estados sirve para limitar combinaciones imposibles o peligrosas.
Esto también reduce la dependencia de la interfaz. No importa si la acción procede de una API, un panel de administración, un webhook, una automatización o un agente de IA. El dominio debe responder a la misma pregunta: ¿es válida esta operación para este objeto en su estado actual?
Cuando esa regla vive solo en la interfaz, basta con que aparezca un segundo canal para que el sistema empiece a aceptar situaciones incoherentes.
¿Por qué no copiar los estados del PSP directamente a tu negocio?
Porque el estado externo pertenece al modelo del proveedor.
Tu sistema tiene su propio dominio.
Un PSP puede llamar authorized a un estado. Otro puede usar approved. Un tercero puede combinar autorización y captura en un único resultado para cierto método. Otros pueden tener estados específicos para análisis, confirmación asíncrona o liquidación.
Una aplicación multi-PSP que distribuye directamente todos esos estados por el código obliga a pedidos, suscripciones, soporte, conciliación y otros sistemas internos a conocer el vocabulario de cada integración.
Una alternativa consiste en normalizar los eventos externos en conceptos propios.
El objetivo no es borrar las diferencias entre proveedores, sino evitar que las particularidades de la integración se propaguen por toda la arquitectura.
Si una capacidad cambia realmente el comportamiento financiero, debe seguir siendo explícita. Una buena abstracción simplifica lo que se puede simplificar y conserva lo que no puede tratarse como equivalente.
¿Deberían el pago y el intento de pago ser la misma entidad?
En operaciones sencillas, puede parecer suficiente.
En arquitecturas más avanzadas, separar ambos conceptos puede resultar muy útil.
El pago representa la intención comercial. Un intento representa un esfuerzo concreto por ejecutar esa intención mediante una ruta, un procesador o una credencial determinados.
Imagina una compra de R$ 500. El primer intento sufre un timeout en el PSP A. Tras investigar, la infraestructura concluye que es seguro volver a intentarlo. El segundo pasa por el PSP B.
Si ambos se tratan simplemente como «el pago», resulta difícil saber qué proveedor recibió cada solicitud, qué autorización pertenece a cada intento y qué evento asíncrono actualiza cada operación.
Esta separación es fundamental para el failover, el Smart Routing y la observabilidad.
Permite que la intención comercial siga siendo única mientras el sistema registra eventos técnicos distintos relacionados con ella.
¿Debe el pedido seguir el mismo estado que el pago?
No necesariamente.
Pedido y pago son dominios relacionados, pero diferentes.
Un pedido puede estar esperando existencias mientras el pago está autorizado. Puede estar listo para el envío mientras la captura sigue procesándose. Puede cancelarse comercialmente y, como consecuencia, desencadenar una operación financiera adecuada al estado actual del pago.
El error arquitectónico aparece cuando un único campo intenta representar ambos universos.
Un estado de pedido como «pagado» puede resultar cómodo al principio, pero mezcla el cumplimiento del pedido y las finanzas.
Un modelado mejor permite que cada dominio mantenga su propia verdad y reaccione a los eventos relevantes del otro.
Pagos informa de que se ha producido una etapa financiera. Pedidos decide qué significa para las existencias, la expedición, el acceso o la prestación del servicio.
Pedidos informa de que la venta se ha cancelado. Pagos decide si la acción correcta es cancelar una autorización, iniciar un reembolso o no hacer nada.
¿Cuándo debo entregar el producto o servicio?
La respuesta depende del modelo de negocio y del método de pago.
No existe una regla universal que diga que todo producto debe entregarse en la autorización, la captura o la confirmación final.
Un hotel, un marketplace, un SaaS, una tienda de productos digitales y un comercio electrónico de productos físicos tienen riesgos y momentos de cumplimiento diferentes.
Lo importante es explicitar la política.
El equipo debe saber qué evento financiero es suficiente para cada acción comercial. Sin esa definición, distintos sistemas pueden tomar decisiones diferentes ante el mismo estado según qué servicio haya recibido primero el evento.
La máquina de estados del pago no sustituye a las reglas de negocio. Proporciona una base fiable para que esas reglas decidan.
¿Qué debe observarse en cada transición?
No basta con almacenar el estado actual.
Para investigar los pagos, conviene poder reconstruir cómo se ha llegado a él.
Esto puede incluir la hora del cambio, el intento relacionado, la ruta, el PSP, la operación solicitada, el resultado normalizado, los identificadores de correlación y el evento que justificó la transición.
No significa registrar indiscriminadamente cargas de datos sensibles. Significa conservar pruebas operativas suficientes para responder preguntas sin convertir la observabilidad en una filtración de datos.
Cuando el equipo pregunta «¿por qué está este pago en ese estado?», la respuesta no debería depender de abrir varios paneles externos y reconstruir manualmente la historia.
Esa es la conexión entre la máquina de estados y la observabilidad.
¿Cómo plantear una máquina de estados de pagos?
Empieza por el dominio, no por el número de estados que ofrece un PSP.
Pregunta qué hechos financieros necesita distinguir realmente la aplicación.
¿Solo existe una intención creada o ya hay un intento en procesamiento? ¿Existe una autorización válida? ¿Se ha solicitado la captura? ¿Se ha confirmado? ¿Se canceló una autorización antes de la captura? ¿Se ha solicitado un reembolso? ¿Ha finalizado total o parcialmente? ¿Existe una disputa posterior? ¿Hay algún resultado que siga siendo desconocido?
Después, define qué transiciones tienen sentido entre esas situaciones.
Solo entonces debes mapear el vocabulario de cada integración externa al modelo interno.
Este orden evita construir el núcleo financiero de la aplicación en torno a las particularidades del primer PSP integrado.
También reduce el coste de añadir proveedores en el futuro, porque la mayor parte del negocio ya trabaja con un modelo estable.
¿Todos los métodos de pago siguen el mismo ciclo?
No.
El modelo de autorización y captura aparece con mucha claridad en las tarjetas, pero no debe diseñarse como si todo medio de pago fuese una tarjeta disfrazada.
Pix, boleto, débito, monederos, transferencias y métodos locales tienen ciclos, confirmaciones, vencimientos y posibilidades diferentes.
Algunos no tienen una etapa equivalente a la autorización separada de la captura. Otros tienen la confirmación asíncrona como comportamiento normal. Algunos permiten determinados tipos de devolución y otros siguen reglas distintas.
Por eso, una abstracción de pagos necesita separar los conceptos compartibles de las capacidades específicas.
El dominio puede compartir ideas como intención, intento, éxito, fallo, devolución y eventos, pero no debería forzar operaciones inexistentes sobre un método solo para mantener una API visualmente uniforme.
Una interfaz coherente es útil. Una interfaz que oculta diferencias financieras relevantes es peligrosa.
¿Por qué importa este modelo en una arquitectura multi-PSP?
Porque varios proveedores amplifican todas las ambigüedades.
Ya no hay un único conjunto de estados, sino varios. No hay una única política de timeout, sino varias. No hay un único webhook: existen formatos, códigos y órdenes de eventos diferentes.
La función de una capa de orquestación no es simplemente elegir el PSP A o el PSP B.
También debe saber qué operación se está ejecutando, qué intento se está modificando, qué estado se ha alcanzado y qué sigue estando permitido hacer.
El enrutamiento sin estado puede elegir una ruta.
El enrutamiento con estado puede evitar que una decisión técnicamente válida produzca una consecuencia financiera incorrecta.
Esta es una diferencia importante entre conectar varios proveedores y operar realmente los pagos como infraestructura.
¿Cómo se relacionan la autorización, la captura y el reembolso con la idempotencia?
Cada una de estas operaciones puede producir efectos financieros.
Esto significa que los reintentos deben controlarse.
Si una solicitud sufre un timeout, repetirla a ciegas puede no ser seguro. La idempotencia permite asociar las solicitudes repetidas a una misma intención cuando el proveedor ofrece ese mecanismo.
Pero una clave de idempotencia no resuelve todo el ciclo de vida.
También hay que correlacionar respuestas, webhooks, intentos y cambios de estado.
La idempotencia evita determinados efectos duplicados. La máquina de estados ayuda a determinar si una operación todavía debería producirse.
Ambos mecanismos se complementan.
Una arquitectura resiliente necesita tanto controlar la repetición como comprender el estado financiero actual.
El error más peligroso es confundir la ausencia de respuesta con una respuesta negativa
Un rechazo explícito contiene información.
Un timeout indica que falta información suficiente.
Estas situaciones no deberían producir automáticamente la misma transición.
Si el emisor ha rechazado la autorización, existe un resultado conocido. Si la red ha dejado de responder a mitad de la solicitud, el sistema puede no saber aún si la operación se ha procesado.
Convertir ambos casos en «ha fallado» elimina una distinción que puede ser esencial para evitar duplicidades.
En sistemas distribuidos, los estados intermedios no son una debilidad del modelo. Representan la realidad con mayor fidelidad.
¿Cómo aparece este ciclo en una plataforma de pagos?
Una plataforma de pagos debe traducir las operaciones externas a un dominio coherente sin fingir que todos los proveedores son iguales.
En AZPay, la autorización, la captura, la cancelación, el reembolso y las actualizaciones asíncronas se tratan como partes distintas del ciclo de un cobro. La captura manual es una operación específica sobre un cobro previamente autorizado, y los cambios posteriores de estado pueden seguirse mediante la API y los webhooks.
Este diseño importa en una infraestructura que integra varios proveedores, porque cada conector puede representar las respuestas externas de forma diferente, mientras el resto de la plataforma necesita un lenguaje operativo coherente.
La abstracción no elimina las particularidades de cada adquirente o PSP. Crea un punto controlado para traducirlas.
¿Qué gana la arquitectura al modelar correctamente el ciclo de vida?
Primero, seguridad operativa. Las operaciones incompatibles con el estado actual pueden bloquearse antes de llegar al proveedor.
Segundo, soporte. El equipo puede explicar lo sucedido sin traducir manualmente decenas de códigos externos.
Tercero, observabilidad. Las métricas pueden organizarse por etapa del ciclo: autorización, captura, reembolso, latencia y fallo técnico.
Cuarto, resiliencia. Los timeouts y los eventos tardíos dejan de exigir decisiones precipitadas.
Quinto, portabilidad. Añadir otro PSP no obliga a toda la aplicación a aprender un nuevo lenguaje financiero.
Y, por último, automatización. Cuantas más decisiones ejecuten los sistemas, las reglas o los agentes, más importante será disponer de estados explícitos y transiciones controladas.
Automatizar un flujo mal modelado solo hace que los errores sucedan más deprisa.
¿Cuál es la diferencia entre autorización, captura, cancelación y reembolso?
La autorización comprueba si la operación puede continuar y, en los flujos de tarjeta compatibles, establece el compromiso necesario para una captura posterior.
La captura confirma que un importe autorizado debe avanzar hacia el cobro.
La cancelación antes de la captura interrumpe una autorización o un cobro que todavía no ha completado el efecto financiero esperado.
El reembolso devuelve total o parcialmente el importe de un cobro que ya ha avanzado en el ciclo.
El término brasileño «estorno» debe manejarse con cuidado porque, en el uso habitual, puede representar más de una de estas operaciones.
La liquidación llega después y pertenece al movimiento financiero entre los participantes del ecosistema. Está vinculada al pago, pero no es sinónimo de autorización o captura.
Esta distinción es pequeña en el vocabulario y enorme en la arquitectura.
El estado de un pago forma parte de la infraestructura
Un sistema de pagos no termina cuando consigue enviar una solicitud a un adquirente.
Debe saber qué ha enviado, qué ha ocurrido, qué puede ocurrir todavía y qué operaciones siguen siendo válidas.
Eso es lo que convierte una integración en infraestructura.
Cuando los estados están bien modelados, la autorización, la captura, la cancelación y el reembolso dejan de ser endpoints aislados y pasan a formar un ciclo coherente.
Los webhooks dejan de ser actualizaciones arbitrarias y pasan a representar transiciones.
El failover deja de significar únicamente «prueba otro PSP» y empieza a respetar lo que ya ha ocurrido.
La observabilidad deja de mostrar solo solicitudes y empieza a mostrar la historia financiera de la transacción.
Y la aplicación deja de preguntar simplemente si un pago «ha salido bien».
Pasa a saber dónde está el pago, cómo ha llegado ahí y qué puede ocurrir a continuación.