Estados de pago en efectivo y sin pago
Customer App puede mostrar estados de pago en efectivo, tarjeta contra entrega, otros métodos, billetera o que parece no requerir pago. Son estados de pago y cobro; no demuestran que el saldo actual sea autorizado ni que se haya realizado un pedido.
Aunque el saldo sea cero o aparezca “No se necesita un pago”, aún se pueden bloquear el carrito, ejecutar comprobaciones contra abusos, crear pedidos, trabajar con billeteras o fidelidad, tareas, complementos, sockets, notificaciones y otros efectos posteriores. Nunca es una ruta segura de solo lectura para realizar un pedido.
Distinguir el tipo de pago de la liquidación
| Estado visible | Interpretación segura | Qué no demuestra |
|---|---|---|
| Método Efectivo | Ordering.co puede registrar la opción de pago en efectivo e información opcional sobre el efectivo entregado. | Que el efectivo sea suficiente, que se acepte el método, se haya cobrado, se deba dar cambio o se haya realizado el pedido. |
| Tarjeta contra entrega | Ordering.co puede registrar un pago con tarjeta no efectuado en línea para cobrarlo después en la operación. | Autorización en línea, disponibilidad del dispositivo, cobro correcto ni realización del pedido. |
| Método en línea/proveedor | Se puede iniciar una selección, desafío, retorno o confirmación específica del proveedor. | Liquidación del pago o pedido en Ordering.co. |
| Saldo que parece cero/gratis | La presentación actual del carrito considera que el saldo es cero y oculta las opciones habituales de pago. | Total final canónico, ausencia de movimiento de billetera, ausencia de cambios en el pedido ni realización correcta. |
| Saldo positivo sin método | El pago todavía requiere un método de pago aceptado. | Que estén disponibles Efectivo, Tarjeta contra entrega u otra opción. |
La visibilidad del método depende del carrito, negocio, cuenta, tipo de pedido, configuración, proveedor y dispositivo actuales. Que falte un método no revela por qué no está disponible.
La interfaz de efectivo y su persistencia son distintas
La interfaz de efectivo puede aceptar un importe entregado y compararlo con el total del pedido que se muestra actualmente. Esa comparación del cliente no es una validación financiera autorizada. Después, los datos de efectivo siguen una ruta genérica de persistencia del método de pago que puede actualizarse por separado del campo visible.
| Capa | Límite |
|---|---|
| Estado de efectivo ingresado | Solo es una entrada local; puede estar incompleta, mal formada, borrada o por debajo del total mostrado. |
| Validación retrasada | Un temporizador breve del cliente retrasa el análisis y envío del valor; una función de retorno anterior puede quedar obsoleta tras cambios de entrada, carrito, total, método o pantalla. |
| Error local de importe suficiente | Impide continuar con la presentación actual de Realizar pedido; no valida el pago en efectivo en el servidor. |
| Persistencia del método de pago | Guarda el método/datos de pago mediante el controlador del proceso; la respuesta, actualización del carrito y autoridad de Realizar pedido son independientes. |
| Realización del pedido en el servidor | Debe volver a validar el saldo, reglas de efectivo, revisión del carrito, cuenta, negocio, moneda y política del pedido actuales. |
Salir del campo, cambiar el método o ver desaparecer un error no demuestra que se haya cancelado el trabajo obsoleto del temporizador ni que el pago guardado coincida con el carrito actual.
Autoridad del saldo, totales y pedidos gratuitos
La rama que parece gratuita se elige según el saldo del carrito actual disponible para la interfaz. El saldo, subtotal, descuentos, cupones, tarifas, impuestos, propinas, uso de billetera, fidelidad, reembolsos y eventos de pago pueden tener fuentes y revisiones independientes.
Antes de realizar el pedido, se debe volver a validar un saldo mostrado como cero con un importe y moneda bloqueados en unidades menores, autorizados por el servidor. Los cambios de productos, cantidades, opciones, negocio, dirección, entrega, horario, cupón, propina, billetera o cuenta pueden invalidar el estado que parecía gratuito.
No infieras que un carrito gratuito carezca de consecuencias financieras, entrega, notificaciones, fraude, impuestos, tarifas, fidelidad o contabilidad.
Realizar pedido, bloqueo, idempotencia y reCAPTCHA
Realizar pedido es una operación destructiva independiente para los estados en efectivo, tarjeta contra entrega, pago en línea, billetera y saldo que parece gratuito.
| Requisito | Límite seguro |
|---|---|
| Revisión actual del carrito | El producto, opciones, importe, dirección, entrega, cliente y negocio deben coincidir con los datos para realizar el pedido. |
| Bloqueo del servidor | Una sola operación actual es responsable de realizarlo; que aparezca un estado ocupado no demuestra un bloqueo duradero. |
| Recibo de idempotencia | Los intentos repetidos, simultáneos, reiniciados o con respuesta perdida deben resolverse en un solo resultado de operación. |
| reCAPTCHA o protección contra abusos | El resultado del desafío debe vincularse a la misma operación actual; no es aprobación de pago ni pedido. |
| Validación del tipo de pago | El estado de efectivo/gratis/proveedor/billetera debe validarse en el servidor frente al carrito bloqueado. |
| Resultado autorizado | Debe identificar la liquidación aceptada, rechazada, en conflicto, parcial o desconocida sin exponer datos privados de la operación. |
Que el control Realizar pedido esté habilitado o se haya completado el desafío es un estado local previo a la acción, no autorización para inferir que tuvo éxito.
Efectos posteriores en billetera, pedidos, tareas, sockets y complementos
Incluso sin un cobro en línea, realizar el pedido puede afectar varios sistemas:
- registros del carrito y del pedido;
- reservas, débitos, créditos, reversiones o acumulación de billetera o fidelidad;
- resumen financiero y de pago/tipo de cobro;
- tareas en segundo plano, entrega, notificaciones e informes;
- acciones de complementos o webhooks;
- eventos de socket y estado local del pedido/carrito; y
- navegación a la superficie de pedido devuelta.
Estas etapas requieren un contrato de operación recuperable. La navegación, aviso, carrito vacío o pantalla del pedido no demuestra que todos los efectos posteriores se hayan actualizado exactamente una vez.
Resultados parciales y desconocidos
| Resultado observable | Interpretación segura |
|---|---|
| Aparece tarde un error de efectivo | La comprobación retrasada del cliente usó un estado de entrada/total; el pago guardado y el carrito actual aún pueden diferir. |
| Desaparece el error de efectivo | Cambió la suficiencia local; no se deduce el recibo del método ni de Realizar pedido. |
| Un estado que parecía gratuito cambia a pago | Cambió una capa que afecta al saldo; la autoridad anterior para realizar el pedido está obsoleta. |
| Realizar pedido sigue ocupado | El bloqueo, desafío, pago, billetera, pedido, tarea o respuesta aún pueden estar pendientes. |
| Se acepta el desafío, pero Realizar pedido da error | La protección contra abusos y la realización son independientes. |
| Aparece el pedido, pero siguen incoherentes el carrito o la billetera | La liquidación es parcial; no consideres completa la operación. |
| Se vacía el carrito, pero no aparece un pedido | Las etapas del carrito y del pedido divergen; el resultado sigue siendo desconocido. |
| Se pierde la respuesta o se reinicia la aplicación | No repitas Realizar pedido automáticamente sin el recibo de operación original. |
| Los carritos agrupados se actualizan de forma distinta | Se requieren la pertenencia exacta del grupo y resultados por carrito; no infieras éxito de todo el grupo. |
Límites de invitado, sesión y proveedor
El estado de invitado o una cuenta recién convertida pueden cambiar la disponibilidad de pagos y la autoridad para realizar el pedido. Una capacidad de invitado, resultado de Iniciar sesión/Registrarse, función de retorno de proveedor o estado de instalación de notificaciones debe pertenecer a la misma cuenta, proyecto, sesión, carrito y generación de operación actuales.
Las rutas de efectivo o saldo gratuito no omiten las reglas obligatorias de identidad, dirección, estudiante, invitado, cupón, tarjeta, billetera, proveedor ni otros requisitos del pago.
Solucionar problemas de forma segura
- Considera sin resolver el valor de efectivo y su validación retrasada hasta que coincidan el carrito y método actuales.
- Un mensaje que indica que no se necesita pago no demuestra que Realizar pedido no tenga efectos o requisitos.
- No uses otro método de pago, billetera, cupón, propina o cambio del carrito para probar un resultado desconocido.
- No repitas Realizar pedido, confirmación, reCAPTCHA ni trabajo del proveedor después de perder una respuesta sin un recibo de operación autorizado.
- Mantén fuera de diagnósticos los pagos, importes, referencias de carrito/pedido/cuenta, datos financieros, resultados del desafío, valores del proveedor y capturas.
- Usa únicamente clases de estado sin valores, como “pago en efectivo sin resolver” o “realización con saldo gratuito desconocida”.
Accesibilidad y privacidad
El tipo de pago, campo, validación local, saldo, mensaje de no pago, método, billetera, Realizar pedido, protección contra abusos, estados ocupado, error, parcial, desconocido y retorno seguro requieren nombres semánticos, roles, valores, consecuencias, orden del foco y anuncios claros. El texto grande, teclado, lector de pantalla, Atrás, cuadro modal y retorno del proveedor no deben ocultar el estado actual del pago o la operación.
Las opciones de pago sin efectivo dependen de los métodos disponibles para el comercio y el pedido. Revisa el total y el método seleccionado antes de confirmar.
Guías relacionadas: Revisar los límites de los métodos de pago · Revisar tarifas, impuestos y propinas · Revisar billeteras y fidelidad · Revisar cupones · Entender los errores y reintentos del pago · Revisar el carrito antes del pago