Límites de pagos
Usa esta referencia para mantener como etapas distintas la presentación del pago, el envío del pedido, la transferencia a un proveedor de pagos externo y la resolución de Ordering.co. Esta guía no establece la ejecución de pagos.
Que un método esté visible, termine una transferencia externa, llegue un callback o se salga de checkout no demuestra que se haya realizado o pagado un pedido. Solo el resultado actual y autorizado de Ordering.co puede establecer el estado final de la aplicación.
Modelo de responsabilidades
| Capa | Responsabilidad | No demuestra |
|---|---|---|
| Customer App | Presentar el estado de checkout actual, requisitos previos, opciones disponibles y estado seguro | Elegibilidad, disponibilidad del proveedor ni resolución final |
| Servicios de Ordering.co | Autorizar al cliente y el carrito, validar importe y método, iniciar el envío y conciliar el resultado autoritativo del pedido/pago | Disponibilidad de un servicio externo ni capacidad del dispositivo |
| Sistema operativo | Informar de la capacidad de plataforma y controlar la presentación o transferencia correspondiente | Autorización de Ordering.co, éxito del cargo ni creación del pedido |
| Servicio de pagos externo | Controlar su propia superficie de recopilación y respuesta de transacción | Que Ordering.co haya aceptado la respuesta o creado el pedido |
La configuración del negocio y del proyecto puede reducir los métodos candidatos, pero la configuración y la presentación no son autorización.
Modelo seguro requerido para el estado del pago
Este modelo define los límites que debe cumplir un flujo de pago. No describe un contrato de operación unificado establecido por las rutas actuales de Customer App. Trata cada transición como observable de forma independiente:
- Elegibilidad: Customer App recibe un método que podría corresponder al negocio, cliente, carrito, importe y dispositivo actuales.
- Acción del cliente: el cliente solicita deliberadamente el siguiente paso.
- Envío en Ordering.co: Ordering.co valida el carrito actual y crea o reanuda una única operación de pago.
- Transferencia externa: el sistema operativo o servicio externo puede devolver una cancelación, fallo, indicación de éxito o ningún resultado concluyente.
- Resolución de Ordering.co: Ordering.co concilia ese resultado con la misma operación autorizada y devuelve el estado autoritativo del pedido/pago.
No combines estas etapas en un único resultado de «pago». En particular, una indicación externa de éxito aún requiere resolución de Ordering.co.
Elegibilidad no equivale a disponibilidad
Que aparezca una opción de pago, instrumento guardado, saldo de Wallet o ruta de finalización no demuestra que esté disponible para un cliente, negocio, dispositivo o pedido concreto. Verifica por separado la presentación y:
- autorización actual del cliente y del carrito;
- importe, moneda y revisión del carrito;
- capacidad del sistema operativo;
- disponibilidad del servicio externo; y
- resolución final de Ordering.co.
Enmascara y minimiza las referencias de instrumentos guardados y los saldos de Wallet. Nunca uses lo que aparece en la interfaz como evidencia de que se puede cobrar un instrumento o de que hay fondos disponibles.
Resultados desconocidos y reintentos
Cerrar la transferencia, agotar el tiempo, perder la conexión, reiniciar la App, recibir un error de callback o no recibir respuesta puede dejar el resultado como desconocido. Desconocido no significa fallido, cancelado, no pagado ni completado.
Cuando el resultado sea desconocido:
- No repitas automáticamente el envío, pago, confirmación ni trabajo del proveedor.
- Un flujo de pago debe consultar el estado de una operación autorizada de Ordering.co sin iniciar otra acción financiera.
- Esa implementación debe mantener la misma identidad de operación y revisión del carrito durante la conciliación.
- Solo debe presentar un estado final después de que Ordering.co devuelva un resultado autoritativo.
Las rutas actuales de la aplicación no establecen un recibo unificado de estado de operación ni un contrato de recuperación automática segura.
Los cambios de cuenta, proyecto, carrito, importe, moneda o sesión invalidan una transferencia pendiente hasta conciliarla de manera segura.
Implementación y verificación seguras
Un flujo de pago debe:
- usar una única identidad de operación idempotente durante el envío, transferencia, callback, conciliación y lecturas de estado seguras para reintento;
- validar toda intención devuelta contra la cuenta, proyecto, carrito, importe, moneda, revisión y vigencia previstos antes de usarla;
- permitir solo destinos externos y mensajes de retorno aceptados; los orígenes, cargas y rutas desconocidos deben fallar de forma segura;
- mantener datos de pago, credenciales, identificadores de proveedores, datos de clientes y detalles de solicitudes internas fuera de registros, URL, ejemplos, capturas y tickets de soporte;
- cancelar o ignorar callbacks obsoletos tras el cierre de sesión, cambio de cuenta/proyecto/carrito o desmontaje; y
- verificar estados deshabilitados, no disponibles, cancelados, fallidos, pendientes y desconocidos con fixtures sintéticos aislados y cero efectos externos.
No recopiles información de pago, crees o elimines un instrumento, inicies un pago, abras una superficie externa de pago ni pruebes una transferencia en vivo para documentarla.
Responsabilidad ante fallos
Un método está visible, pero no disponible
Vuelve a comprobar los requisitos actuales del cliente, carrito, negocio, importe, dispositivo y método. No trates la opción visible como derecho de acceso ni indicador de estado del proveedor.
Se cierra la transferencia externa o muestra un error
Conserva la operación actual y vuelve al estado de Ordering.co. No deduzcas solo del mensaje externo si se movió dinero.
La App vuelve a checkout sin resultado final
Considera desconocido el resultado. Concilia mediante la operación existente en vez de crear otro intento de envío o pago.
Cambió la cuenta, proyecto, importe o carrito
Detén el flujo pendiente. Un resultado del contexto anterior no debe actualizar ni navegar al contexto nuevo.
Seguridad y disparadores de cambio
Vuelve a validar este límite tras cambios en elegibilidad de métodos de pago, reglas de revisión de carrito/pedido, autoridad de importe/moneda, gestión de instrumentos guardados, capacidad de plataforma, destinos o mensajes externos, callbacks, idempotencia, recuperación de estado, desmontaje de sesión/proyecto o versiones de App, componentes compartidos o API.
La documentación pública debe ser independiente del proveedor. No publiques valores de configuración, credenciales, identificadores, tokens, endpoints, formatos de carga ni instrucciones de pruebas en vivo.
Referencias relacionadas: Límites de integraciones nativas · Elegir un método de pago · Estado de checkout y reintentos · Límites de configuración de Customer App