La detección de transacciones, la confirmación en la cadena, la asociación con el pedido y la entrega del servicio son pasos separados. Verifique la cadena, el activo, el destinatario y el importe correctos; aplique una política de aceptación documentada; y haga que la conciliación sea idempotente. Una referencia de transacción, una captura de pantalla o un botón del navegador por sí solos no pueden establecer que un pedido específico haya sido pagado.
Separe el evento de la cadena del evento del pedido
Que una cartera informe que se envió una transferencia es evidencia sobre su propia acción, no una decisión completa de pago. El backend receptor debe observar la red prevista, verificar la transferencia real y asociarla con un pedido. Solo entonces el pedido puede aplicar su política de aceptación. La entrega de la infraestructura es otro paso operativo posterior a la aceptación del pago.
Mantenga estas transiciones explícitas tanto en el código como en el lenguaje dirigido al cliente. Una pantalla puede mostrar en espera, detectado o confirmando sin declarar el pedido como pagado. No permita que el navegador proporcione el importe aceptado ni sobrescriba un estado autoritativo. Almacene la cotización creada por el servidor y sus instrucciones para que la conciliación posterior pueda evaluarse contra el pedido original en lugar de un carrito cambiante.
Use reglas de confianza específicas de cada cadena
Las distintas redes describen la confianza de una transacción de manera diferente. La guía para desarrolladores de Bitcoin explica cómo los nodos seleccionan la cadena con la mayor prueba de trabajo acumulada y cómo pueden producirse bloques competidores. Por lo tanto, una transacción vista recientemente necesita una política de profundidad de confirmación y posibles cambios de cadena. No existe un único número de confirmaciones apropiado para cada activo y riesgo comercial.
La documentación de prueba de participación de Ethereum explica la finalidad por puntos de control, mientras que Solana documenta los estados de compromiso procesado, confirmado y finalizado. No traduzca esos términos a la ligera como un único recuento universal de bloques. Registre la regla específica de la red, la fuente de información y el comportamiento durante la incertidumbre. El operador debe determinar los umbrales de aceptación en función del riesgo de pago y entrega, no copiar un número de un proceso de pago no relacionado.
Verifique la carga útil real de la transferencia
Identifique el destinatario, el activo y el importe en la cadena correcta. Los pagos con tokens necesitan la identidad del token previsto, no solo una transacción exitosa a una dirección. Verifique el éxito de ejecución relevante y la evidencia de transferencia según el modelo de la cadena. Analice los importes enteros con la precisión adecuada del activo en lugar de confiar en un decimal formateado proporcionado por el navegador.
Una instrucción de pago debe permanecer vinculada a su ruta original. Una transferencia en otra red, un token diferente con el mismo símbolo o una referencia de transacción no relacionada no deberían satisfacerla. El registro de verificación debe explicar qué se comprobó y conservar la evidencia necesaria para revisar la decisión. Esta guía describe principios generales de conciliación de pagos en lugar de una implementación de servicio concreta.
Haga que la asociación con el pedido sea inequívoca
Las direcciones de recepción fijas pueden recibir varios pedidos con importes similares. La existencia de una transferencia coincidente no demuestra qué cliente o pedido debe recibir el crédito. Defina el método de asociación antes de aceptar pagos reales e incluya el manejo de colisiones. Una referencia de transacción proporcionada por el usuario aún requiere validación de que la misma transferencia no haya sido asignada ya en otro lugar.
Imagine dos facturas por el mismo importe en la misma ruta durante una ventana superpuesta. Un observador ve una transferencia. Marcar automáticamente ambas como pagadas es incorrecto; elegir una sin suficiente evidencia también es inseguro. Mantenga la transferencia sin asignar o en revisión hasta que la política del operador pueda establecer una asociación válida. Una coincidencia ambigua es un estado que debe gestionarse, no una razón para fabricar certeza.
Defina estados que toleren evidencia tardía y cambiante
Un proceso de pago se beneficia de un conjunto pequeño de estados claros, con la evidencia de la cadena separada de la decisión de aceptar un pedido. Esta tabla ilustrativa explica posibles etapas en lugar de describir los nombres de estado de un servicio concreto. Cada transición debe tener una razón verificada, y la aceptación del pago debe permanecer distinta de la entrega de la infraestructura.
Incluya transferencias tardías, parciales y en exceso, la expiración de cotizaciones y datos de cadena temporalmente no disponibles. La expiración no hace desaparecer una transferencia real. Un pago tardío puede requerir revisión en lugar de aceptación o rechazo automáticos. Si un evento de cadena observado previamente cambia, vuelva a evaluar el estado según la política documentada en lugar de tratar cada notificación del observador como una verdad irreversible.
| Estado ilustrativo | Significado | Siguiente decisión |
|---|---|---|
| En espera | Ninguna transferencia válida verificada | Seguir observando la factura válida |
| Detectado | Transferencia relevante observada | Comprobar la confianza de la cadena y la asociación |
| Confirmando | Regla de aceptación aún no cumplida | Observar hasta que la política permita decidir |
| Revisión | Evidencia tardía, parcial o ambigua | Resolver según la política del operador |
| Aceptado | Pago verificado y conciliado | Continuar con el flujo de entrega separado |
Haga que los reintentos sean seguros y observables
Los observadores y los trabajos de conciliación reintentarán tras conexiones interrumpidas o reinicios de procesos. Use una identidad de transferencia estable, como la cadena y el identificador de transacción o transferencia adecuado, para evitar créditos duplicados. Persista el progreso y las decisiones para que el mismo evento pueda procesarse de nuevo sin aprovisionar un segundo servicio ni modificar una cotización aceptada.
Distinga un resultado desconocido de una operación fallida. Si una solicitud descendente agota el tiempo de espera, inspeccione su resultado autoritativo antes de reenviarla. Mantenga registros duraderos de las acciones aceptadas e inciertas. Restrinja el acceso a los tokens de pedido y a la evidencia interna, conservando suficiente información para investigar un pago en disputa. La fiabilidad aquí se refiere a decisiones repetibles, no a una animación fluida en el proceso de pago.
Sepa qué necesita aún un pedido pendiente
Un pedido puede permanecer pendiente porque no se ha observado la transferencia, no se ha alcanzado la confianza de cadena requerida o su asociación con la factura necesita revisión. Conserve la factura y la referencia pública de la transacción, compruebe las reglas de aceptación indicadas y utilice el proceso de asistencia previsto para el pedido. Una actualización de estado retrasada no es, por sí misma, una razón para enviar otro pago.
Siga las instrucciones y el estado verificado del pedido real. La confirmación del pago debe identificar la aceptación de la transferencia conciliada, mientras que la entrega del servicio tiene un estado separado. Mantenga los tokens de acceso privados y los secretos de la cartera fuera de las solicitudes de ayuda.
Su lista de verificación práctica.
- Persista una cotización inmutable creada por el servidor.
- Verifique la cadena, el destinatario, el activo y el importe entero.
- Documente reglas de aceptación específicas de cada cadena.
- Gestione las colisiones de direcciones fijas sin adivinar.
- Evite créditos duplicados y reenvíos de reintento inseguros.
- Pruebe casos de transferencias tardías, parciales, de ruta incorrecta y con evidencia cambiante.
Los detalles que importan.
¿Basta un hash de transacción para confirmar el pago?+
No. Verifique la transferencia en la cadena prevista, su carga útil y su confianza, y luego establezca que pertenece al pedido y que no ha sido ya acreditada.
¿Puede toda red usar el mismo umbral de confirmación?+
No. Las redes exponen modelos de confianza y finalidad diferentes. El operador debe definir y probar una política de aceptación adecuada para cada ruta.
¿Un pago confirmado significa que el servidor está aprovisionado?+
No. La aceptación del pago y la entrega son eventos de flujo de trabajo separados. Comunique el estado de aprovisionamiento desde su propio proceso autoritativo.
Vaya a la fuente.
Estas referencias respaldan los conceptos técnicos de esta guía. Consulte la documentación actual antes de cambiar un sistema de producción.
- Guía para desarrolladores de Bitcoin: comportamiento de la cadena de bloques developer.bitcoin.org
- Ethereum: prueba de participación y finalidad ethereum.org
- Solana: compromiso de estado RPC solana.com
Orientación editorial de SwissOctet. Los ejemplos son ilustrativos. Las especificaciones del servicio, las opciones disponibles y las condiciones contractuales deben verificarse por separado.