Entender los estados de recuperación del pago
El pago puede seguir pendiente mientras Customer App lee el carrito, reanuda un paso a un proveedor de pagos externo, confirma un carrito o grupo, busca un pedido o concilia el estado del proveedor y Ordering.co. Que aparezca como pendiente, parezca fallido o se cierre la superficie del proveedor no establece si se produjeron efectos de pago, billetera, pedido o reembolso.
La postura segura para el cliente es esperar, revisar Pedidos y no repetir mientras no se haya resuelto la liquidación. Actualizar, reabrir Pago, cambiar el método, usar Atrás, volver a la aplicación o repetir Realizar pedido/Confirmar no es una prueba de diagnóstico. Estos eventos pueden iniciar más trabajo de recuperación o del proveedor.
Reconocer el estado de recuperación
| Estado visible | Interpretación segura |
|---|---|
| Pago cargando | No se han resuelto el estado del carrito, cuenta, configuración, pago, billetera o pedido |
| Pendiente/en proceso | Una realización, tarea del proveedor, confirmación o búsqueda de pedido puede seguir en curso o esperando conciliación |
| Mensaje que parece de fallo | Una capa informó un error; no demuestra que no se haya producido ningún efecto de pago, billetera, pedido o proveedor |
| Superficie del proveedor abierta | Hay trabajo pendiente en el proveedor externo o integrado; la actualización de Customer App es independiente |
| Se cerró la superficie del proveedor | Se cerró la superficie o se gestionó Atrás; no se distinguen cancelación, fallo, confirmación ni ausencia de efecto |
| Customer App vuelve a Pago | Cambió el estado de foco/primer plano/navegación y puede iniciar otra lectura o rama de recuperación |
| Aparece un pedido en Pedidos | Ordering.co muestra un pedido asociado a la cuenta actual; el estado del proveedor y del grupo aún puede ser independiente |
| No aparece ningún pedido | La ausencia en una vista no demuestra que no ocurrieran la realización o el pago |
No interpretes un aviso, botón deshabilitado, navegación, mensaje del proveedor, resultado de SDK nativo ni cambio de estado del carrito como recibo de una operación ejecutada exactamente una vez.
Desencadenantes de recuperación automática
La fuente actual puede volver a leer y conciliar Pago cuando se monta, recibe foco, vuelve al primer plano, gestiona Atrás/cierre en algunas superficies de proveedor o procesa estado de retorno/consulta. Después, un carrito pendiente puede iniciar trabajo específico del proveedor o una solicitud de confirmación.
Estos desencadenantes no son reintentos del cliente, pero pueden repetir trabajo de recuperación financiera sin un recibo común de generación de operación. No los actives deliberadamente para probar el estado. En particular:
- no actualices ni reinicies la aplicación;
- no salgas de Pago ni vuelvas a abrirlo;
- no envíes la aplicación al fondo y la restaures repetidamente;
- no uses Atrás ni cierres una superficie de proveedor para probar la cancelación;
- no modifiques un enlace o consulta de retorno; y
- no cambies el método de pago para ver si desapareció el intento anterior.
Etapas del proveedor y confirmación
| Etapa | Qué puede significar | Qué no demuestra |
|---|---|---|
| Redirección o paso integrado | Customer App transfirió el trabajo a un contexto de pago externo | Aceptación del proveedor, confirmación de Ordering.co ni creación del pedido |
| Resultado de SDK de pago nativo | Un SDK de plataforma/proveedor devolvió un resultado local | Importe/cuenta/carrito correctos, captura final ni pedido de Ordering.co |
| Se cierra el proveedor o se usa Atrás en PayPal | Se cerró la superficie del proveedor y se puede activar la lógica de confirmación local | Cancelación del cliente, ausencia de cargo ni confirmación exitosa |
| Confirmación de un carrito | Ordering.co intenta conciliar un carrito pendiente | Liquidación del proveedor, existencia del pedido, vigencia de la sesión ni ejecución exactamente una vez |
| Confirmación del grupo | Ordering.co intenta conciliar varios carritos | Pertenencia completa, éxito de todos los miembros, pedido de grupo único ni reversión |
| Búsqueda/navegación del pedido | Customer App busca o abre un pedido devuelto | Finalización del proveedor, billetera, reembolso, mensaje, tarea o socket |
El retorno del proveedor es información para la conciliación de Ordering.co, nunca el estado autorizado de finalización para el cliente por sí solo.
Respuesta perdida y liquidación desconocida
Una solicitud puede confirmarse remotamente mientras se pierde su respuesta. También puede haber un resultado local exitoso del proveedor sin una liquidación aceptada por Ordering.co. La guía segura actual es limitada: Pedidos solo refleja el estado de Ordering.co. Si el resultado sigue sin resolverse, comunícate con un canal de soporte aprobado y no repitas la acción financiera.
Un contrato de recuperación futuro aceptado debe ofrecer un identificador de operación duradero y autorizado y un recibo que muestre solo el estado, vinculado a la cuenta, proyecto, sesión, carrito o grupo, método, importe y generación de operación exactos. Es un requisito contractual futuro, no una capacidad actual de Customer App.
Mientras no esté resuelto:
- no vuelvas a enviar Realizar pedido, Confirmar, pago ni trabajo de billetera;
- no cambies el método ni los datos financieros;
- no crees otro carrito para comprobar si se actualizó el primero;
- no supongas que un error revirtió efectos de pago, billetera, reembolso, pedido, tarea o proveedor; y
- no supongas que una tarjeta de pedido significa que se hayan completado todos los efectos financieros/del grupo.
Pago de un carrito o de un grupo
La confirmación de un carrito y la de un grupo tienen límites distintos de pertenencia y liquidación. El resultado de un grupo puede ser parcial: algunos carritos pueden convertirse en pedidos mientras otros sigan pendientes, fallidos, ausentes o con estado financiero sin resolver.
La navegación a detalles agrupados, un identificador del grupo, un estado de grupo que parece completo o el éxito de un miembro no demuestra la pertenencia exacta ni la finalización de todos los miembros. Conserva por separado el resultado de cada miembro y nunca presentes resultados mixtos como éxito del grupo.
Efectos secundarios de billetera, reembolso y pedido
La realización y recuperación pueden atravesar varios sistemas que se actualizan por separado:
- una reserva, débito, compensación o reembolso de billetera puede diferir del estado del carrito y del pedido;
- se puede crear un pedido antes de la navegación o la respuesta final del cliente;
- la autorización, captura y reversión del proveedor pueden diferir de los eventos de pago locales;
- tareas, complementos, mensajes, sockets y analítica pueden completarse después; y
- cambios de sesión/cuenta/proyecto pueden impedir aplicar de forma segura una respuesta tardía.
La presentación de Customer App no demuestra que esos efectos sean atómicos, reversibles, se ejecuten exactamente una vez o estén completos.
Próximos pasos seguros
- Deja de interactuar con Pago si aparece pendiente o un error ambiguo.
- Espera a que termine la operación actual sin actualizar, reabrir, enviar la aplicación al fondo, cambiar el método ni abrir/cerrar un proveedor para probarlo.
- Revisa una vez la superficie habitual de Pedidos desde la cuenta y el proyecto actuales.
- Si aparece un pedido actual autorizado, usa su estado solo como estado del pedido de Ordering.co; mantén por separado los resultados de proveedor, billetera, reembolso y grupo.
- Si el resultado sigue siendo desconocido, usa un canal de soporte aprobado y describe solo la clase de estado. No envíes datos de pago, mensajes de proveedores, enlaces, tokens, referencias de carrito/pedido ni capturas.
Estos son límites conservadores para evitar reintentos, no un procedimiento de reintento ni de pago.
Solucionar problemas de forma segura
| Síntoma | Respuesta segura |
|---|---|
| Sigue apareciendo Pendiente | Espera; no sigas instrucciones de actualización de una copia antigua de la interfaz |
| Aparece un mensaje que parece un fallo | Considera desconocida la liquidación; no lo intentes inmediatamente otra vez |
| El proveedor se cierra o vuelve inesperadamente | No infieras cancelación/éxito; no toques Pago y concilia Pedidos |
| La aplicación vuelve a Pago al restaurarse | No inicies otro ciclo de foco; la recuperación ya podría estar en curso |
| Pedidos no muestra un artículo nuevo | Conserva el estado desconocido; que no aparezca no demuestra que no haya cargo/pedido |
| Aparece un miembro del grupo | No infieras que se completó el grupo; conserva la incertidumbre por miembro |
| El estado de billetera/proveedor contradice Pedidos | No calcules ni inicies compensación/reembolso; escálalo por un canal aprobado |
| Cambia la cuenta/proyecto durante la recuperación | Descarta la vista anterior y no apliques ni repitas su resultado tardío |
Accesibilidad y privacidad
Los estados de carga, pendiente, parecido a fallo, paso al proveedor, desconocido, pedido confirmado, grupo parcial, conflicto de billetera/reembolso, deshabilitado y no repetir requieren texto y anuncios semánticos claros. Los controles ocupados deben exponer los estados deshabilitado/ocupado; Atrás y cerrar el proveedor requieren consecuencias; el foco no debe saltar a Realizar pedido habilitado después de una recuperación al volver a la aplicación.
El texto grande, teclado, lector de pantalla, movimiento reducido, áreas seguras y Atrás en iOS/Android deben conservar la advertencia y el paso seguro a Pedidos sin provocar una acción duplicada. No expongas datos de pago, billetera, proveedor, cuenta, carrito, grupo, pedido, enlace, token ni error sin filtrar en etiquetas, registros, capturas ni notas de soporte. Estos son requisitos de verificación, no una certificación actual.
Guías relacionadas: Revisar el carrito antes del pago · Entender la disponibilidad de métodos de pago · Entender el pago para varios negocios · Ver pedidos activos y anteriores · Entender los pedidos agrupados · Entender el comportamiento sin conexión y al reconectar