Respuesta rápida: solo una notificación IPN firmada de producción acredita el pago
En EMP un pedido o una reserva nunca se marcan como pagados porque el cliente abra el enlace de pago, regrese desde su navegador o envíe una captura de pantalla por WhatsApp. Tampoco una revisión humana ni una prueba técnica en ambiente sandbox acreditan dinero real.
Para acreditar un cobro al pedido o la reserva, el servidor debe recibir una notificación instantánea de pago (IPN) de producción con resultado de pago válido. Comprueba su firma, referencia y dominio contra la configuración del intento. El IPN confirma el resultado financiero; no prepara el pedido, entrega mercancía ni atiende la cita.
Cómo se genera y protege cada enlace de cobro del negocio
Cada negocio configura su comercio Yappy Comercial V2 en Integraciones, con ID, clave, dominio registrado y ambiente. La configuración se cifra en el servidor; el panel devuelve metadatos e indica si se guardó. Configurado no demuestra que el proveedor haya habilitado el comercio o autorizado el dominio.
Desde Pedidos o Reservas, Cobrar con Yappy crea o recupera el enlace del destino. El importe procede de la operación guardada y el acceso usa un token aleatorio. Copia y comparte el enlace con el cliente correcto: ese control manual no envía WhatsApp. El recorrido automático de pedidos puede enviarlo cuando sus proveedores y worker están configurados.
- Comprueba negocio, referencia, importe y ambiente antes de compartir. El navegador no elige el monto; si cambió desde que se creó el enlace, el servidor rechaza iniciar ese pago.
- El enlace nuevo dura 24 horas. Su página lleva noindex, nofollow; trata el enlace como acceso privado y no lo publiques en redes o documentos abiertos.
- En demo, configuración y cobro están deshabilitados. Sandbox requiere un entorno persistente y habilitación del proveedor: guarda resultados técnicos, pero no acredita dinero real en el pedido o la reserva.
Qué significa cada estado de cobro Yappy y cómo debe actuar tu equipo
El ciclo de vida de un intento de cobro en EMP distingue entre la preparación interna, la espera de confirmación del cliente en su aplicación bancaria, los posibles cortes de red y el resultado final firmado.
| Estado en panel | Qué ocurrió en el servidor | ¿Acredita dinero? | Qué debe hacer el equipo |
|---|---|---|---|
| draft | El enlace está guardado; todavía no se inició la solicitud de pago al proveedor. | No | Comparte el enlace revisado con su destinatario; no lo presentes como comprobante. |
| creating | Se inició la creación de la sesión de pago. | No | Espera el resultado. No repitas la solicitud si permanece detenida: requiere revisión. |
| pending | Se obtuvo una sesión; todavía falta el resultado firmado de pago. | No | Consulta el estado. No asumas que la sesión o el retorno del navegador acreditan pago. |
| uncertain | La petición se despachó y no se pudo confirmar su resultado. | No | No cobres otra vez a ciegas; comprueba la referencia con el comercio y documenta el seguimiento. |
| paid (Producción) | Se recibió y validó el IPN firmado con HMAC en ambiente production. | Sí (estado monotónico) | Continuar con la preparación o atención; revisar el caso reabierto en Revisión humana. |
| paid (Sandbox) | El intento recibió un resultado firmado de prueba; el destino no queda pagado real. | No acredita dinero real | Comprueba también el ambiente, no solo la palabra paid. |
| rejected / cancelled / expired | El intento finalizó negativamente o el borrador venció o fue invalidado localmente. | No | Revisa el intento y la operación antes de iniciar uno nuevo; un resultado tardío puede requerir seguimiento. |
Monotonicidad del estado pagado y reapertura automática de Revisión humana
Las redes móviles y los webhooks pueden entregar notificaciones desordenadas o repetidas. Por eso en EMP el estado paid es estrictamente monotónico: una vez que un cobro de producción ha sido acreditado mediante un IPN firmado válido, ninguna notificación rezagada o reintento posterior puede regresarlo a pending, expired ni cancelled.
La primera acreditación válida de producción también devuelve el caso de Revisión humana a pendiente e incrementa su revisión. Un duplicado no lo vuelve a abrir. Si una pestaña intentaba verificar la versión anterior, debe actualizarse. El panel consulta el estado periódicamente; no se promete una alerta inmediata por otro canal. Este ejemplo es hipotético y no acredita un cobro real ni una integración certificada.
Incertidumbre, cancelaciones y expedientes de conciliación manual
Con un cobro creating, pending o uncertain, el servidor impide cancelar el pedido o la reserva. Para investigar, conserva referencia, importe, hora y resultado registrado; comprueba con el comercio o proveedor qué ocurrió. En Administración puedes abrir un expediente de conciliación y registrar responsable, notas y referencia del proveedor. Cerrar el expediente solo cierra el seguimiento administrativo: no cambia el cobro ni habilita repetirlo.
Si corresponde una devolución de un cobro ya pagado, acuerda el procedimiento con el comercio y el proveedor y documenta la solicitud. EMP no implementa un reembolso bancario automático ni un endpoint de consulta del proveedor. Cancelar la operación o verificar un caso no devuelve dinero. La suscripción de EMP utiliza otro comercio, separado del Yappy de tus clientes.
Antes de continuar
- Comprueba que tu comercio Yappy Comercial V2 esté en ambiente production antes de cobrar a clientes reales.
- Guíate únicamente por el estado paid validado por IPN firmado en el panel, nunca por capturas de pantalla en el chat.
- Ante un estado uncertain, consulta primero el portal de tu comercio Yappy antes de generar otro enlace.
La demo conserva datos en memoria. Las conexiones de proveedores requieren configuración, autorización y verificación en tu entorno persistente.