Automatizar pagos para un comerciante de Binance P2P en Venezuela
parece relativamente sencillo cuando el banco ofrece una API estable.
Recibes una orden. Validás los datos del beneficiario. Ejecutás el pago.
Confirmás la operación. Marcás la orden como pagada.
Con Banco de Venezuela (BDV), el problema cambia por completo.
Para el flujo que necesitábamos automatizar no disponíamos de una API
bancaria convencional que permitiera ejecutar y verificar cada pago
directamente desde Python. Las operaciones debían realizarse dentro de
la aplicación Android de BDV, mientras que las órdenes, los métodos de
pago y la confirmación pertenecían a Binance P2P.
Eso nos obligó a construir un puente entre dos sistemas completamente
diferentes:
Binance P2P ↓ Validación de la orden ↓ Cola de pagos ↓ Android ↓ Banco de Venezuela ↓ Pago Móvil / Transferencia ↓ Verificación del comprobante ↓ Binance P2P Y rápidamente descubrimos algo importante:
la parte difícil no era llenar formularios ni presionar botones.
La parte difícil era decidir qué debía hacer el software cuando había
dinero real involucrado y alguno de esos sistemas no respondía
exactamente como esperábamos.
El reto de automatizar Binance P2P con Banco de Venezuela
El objetivo inicial era construir un sistema capaz de procesar
automáticamente órdenes BUY de Binance P2P utilizando métodos de
pago de Banco de Venezuela.
Principalmente:
- Pago Móvil BDV
- Transferencias bancarias de Banco de Venezuela
En una integración bancaria tradicional, una API podría devolver algo
parecido a:
payment_id: 92839102 status: SUCCESS y posteriormente permitir consultar nuevamente ese estado.
Con una aplicación bancaria Android no tenemos necesariamente esa
garantía.
La interfaz gráfica forma parte del flujo.
El bot debe navegar por BDV, seleccionar el tipo de operación,
introducir los datos, revisar la información, autorizar el pago y
finalmente interpretar el resultado mostrado por la aplicación.
Por eso una de las primeras reglas del proyecto fue:
Botón presionado ≠ pago confirmado El hecho de que Android haya aceptado una acción no demuestra que el
dinero haya sido transferido.
Conectando órdenes BUY de Binance P2P con BDV
El flujo comienza cuando el sistema detecta una nueva orden BUY en
Binance P2P.
Pero detectar una orden no significa que podamos pagarla inmediatamente.
Primero necesitamos obtener sus datos actuales y validar el método de
pago.
Una operación de Pago Móvil puede necesitar:
Teléfono Cédula Banco Monto Mientras que una transferencia bancaria de BDV requiere principalmente:
Cuenta bancaria Monto Datos del beneficiario Y aquí aparece otro problema habitual en automatización P2P:
los datos configurados por un usuario no siempre son correctos.
Por ejemplo, un campo destinado al número de cuenta puede contener una
cédula, un número incompleto o cualquier otro valor inválido.
Para una persona es fácil mirar esos datos y decidir qué hacer.
Un bot financiero no debería "adivinar".
Nuestra regla es mucho más simple:
Datos válidos ↓ Continuar Datos inválidos ↓ NO ejecutar pago En automatización financiera, detener una operación dudosa es mejor que
intentar interpretar lo que probablemente quiso decir el usuario.
Una cola de pagos para múltiples órdenes de Binance P2P
Un comerciante P2P puede recibir varias órdenes prácticamente al mismo
tiempo.
La aplicación de Banco de Venezuela, en cambio, procesa una operación a
la vez.
Ejecutar varias automatizaciones Android simultáneamente sobre la misma
aplicación sería extremadamente peligroso.
Una podría estar escribiendo el monto mientras otra intenta seleccionar
una cuenta.
Por eso construimos una cola persistente de pagos.
Orden Binance #1 ─┐ Orden Binance #2 ─┼──→ Cola ──→ BDV Orden Binance #3 ─┘ Cada orden tiene además su propio estado interno.
De forma simplificada:
QUEUED ↓ PROCESSING ↓ REVIEW_VERIFIED ↓ SUBMITTED ↓ PAYMENT_SUCCESS ↓ RECEIPT_SAVED ↓ RECEIPT_SENT ↓ MARKED_PAID ↓ COMPLETED También existen estados especiales para situaciones donde continuar
automáticamente sería peligroso:
PAYMENT_UNKNOWN RECOVERY_REQUIRED CANCELLED Esto convierte la automatización en algo muy diferente a un simple
script que hace clic en una aplicación Android.
Cada transición importante queda persistida.
Automatizando Pago Móvil BDV desde Android
Para Pago Móvil de Banco de Venezuela, el bot navega hasta el
formulario correspondiente e introduce los datos obtenidos de la orden.
Pero antes de autorizar el pago existe una etapa crítica:
verificar la pantalla de confirmación.
No confiamos simplemente en los valores que el bot intentó escribir.
Verificamos lo que BDV realmente está mostrando antes de enviar el
dinero.
Conceptualmente:
Datos de Binance P2P ↓ Completar formulario BDV ↓ Pantalla de revisión ↓ Comparar datos ↓ ¿Coinciden? │ │ Sí No │ │ ▼ ▼ Continuar BLOQUEAR Monto, destinatario y demás información relevante deben corresponder con
la operación esperada.
Esta verificación es especialmente importante porque estamos
automatizando una interfaz gráfica.
El software no debe asumir que escribir un valor significa que la
aplicación lo recibió correctamente.
Automatizando transferencias bancarias de Banco de Venezuela
Las transferencias bancarias BDV utilizan un flujo diferente a Pago
Móvil.
El bot debe navegar por las opciones de transferencia, seleccionar la
cuenta de origen, introducir la cuenta de destino y completar el monto.
Después vuelve a aparecer una pantalla de revisión.
Para una transferencia verificamos información como:
Cuenta de destino Monto Concepto Solo cuando los valores coinciden se permite continuar.
Durante las pruebas encontramos un buen ejemplo de por qué esta
verificación debe basarse en lo que la aplicación realmente devuelve y
no únicamente en lo que esperamos encontrar.
Una versión del detector esperaba este texto:
Transferencias a terceros BDV Pero el comprobante real de una transferencia exitosa mostraba:
Transferencias a terceros La transferencia había sido realizada correctamente.
El comprobante existía.
El monto era correcto.
La cuenta de destino era correcta.
Sin embargo, una condición demasiado específica impedía reconocer el
resultado.
La solución no fue eliminar verificaciones.
Fue hacerlas más precisas.
Un bug de una palabra puede ocultar una transferencia exitosa
El mismo comprobante reveló otro problema interesante.
BDV mostraba:
Comprobante de operación y posteriormente:
Operación: 059130787505 Un parser demasiado flexible que buscara cualquier texto que contuviera
la palabra operación podía encontrar primero:
Comprobante de operación en lugar del campo real:
Operación: 059130787505 El resultado era paradójico.
La transferencia bancaria había sido exitosa, pero el software no
podía extraer correctamente su referencia.
La corrección consistió en identificar exactamente el campo Operación
en lugar de aceptar cualquier cadena que simplemente contuviera esa
palabra.
Después de corregir ambas diferencias, el mismo flujo podía terminar
así:
Bank Transfer receipt verification: FULL MATCH Payment SUCCESS BDV reference detected Receipt saved Receipt delivered Binance order marked as paid Este tipo de problema es difícil de descubrir viendo únicamente una
demostración donde todo funciona.
Aparece cuando el sistema empieza a enfrentarse a operaciones reales.
El problema más peligroso: una orden puede cambiar mientras BDV está abierto
Existe otra condición de carrera mucho más importante.
Supongamos que Binance informa que una orden está activa.
El bot comienza a preparar el pago.
10:00:00 Orden Binance activa 10:00:03 Comienza operación en BDV 10:00:15 Datos verificados 10:00:20 Estado de Binance cambia 10:00:23 Bot envía dinero Verificar el estado solamente al principio no es suficiente.
La orden pudo expirar o cambiar mientras la aplicación bancaria estaba
siendo procesada.
Por eso implementamos dos controles independientes del estado de
Binance P2P.
El primero ocurre antes de iniciar un nuevo pago en BDV.
El segundo ocurre inmediatamente antes del punto irreversible de la
operación bancaria.
Orden Binance ↓ Verificar estado ↓ ¿Activa? │ │ Sí No │ │ ▼ ▼ BDV CANCELAR │ ▼ Verificar datos │ ▼ Verificar Binance OTRA VEZ │ ├── Orden inactiva → NO PAGAR │ └── Orden activa ↓ PAGAR Si no podemos obtener un estado confiable de Binance en ese momento, la
operación no continúa.
En sistemas financieros preferimos fail closed.
La incertidumbre nunca debe convertirse automáticamente en permiso para
enviar dinero.
Cuando "pago desconocido" NO significa "pago fallido"
Este terminó siendo probablemente el problema de ingeniería más
importante de todo el proyecto.
Imaginemos que el bot llega al último paso y confirma una transferencia.
BDV muestra:
Realizando operación... Pasan varios segundos.
La aplicación sigue procesando.
¿Qué hacemos?
La respuesta aparentemente sencilla sería establecer un timeout.
Pero entonces aparece una pregunta mucho más importante:
¿qué significa realmente ese timeout?
Sabemos que enviamos la operación al banco.
No sabemos todavía si terminó correctamente.
Por lo tanto:
TIMEOUT ≠ FAILED Y, todavía más importante:
UNKNOWN ≠ FAILED Supongamos que enviamos 20.000 VES.
BDV permanece procesando.
Después de 60 segundos el bot decide que el pago falló y vuelve a
intentarlo.
Pero la primera transferencia sí había sido procesada por el banco.
Resultado:
Primer pago 20.000 VES Segundo pago 20.000 VES ────────── Total 40.000 VES Un sistema diseñado para automatizar pagos acaba de automatizar una
pérdida.
Por eso nuestro bot utiliza un estado explícito:
PAYMENT_UNKNOWN Cuando una operación ya pudo haber sido enviada pero no existe evidencia
suficiente para clasificarla como éxito o fallo:
el bot no vuelve a pagar.
Protección contra pagos duplicados en BDV
El punto crítico del sistema es el último botón que autoriza la
operación bancaria.
Antes de ejecutar esa acción persistimos el estado:
REVIEW_VERIFIED ↓ SUBMITTED ↓ Confirmación final BDV El orden es intencional.
Primero:
SUBMITTED Después:
Aceptar ¿Por qué?
Porque el proceso de Python podría cerrarse inmediatamente después de
tocar el botón.
Android podría desconectarse.
Windows podría reiniciarse.
La aplicación BDV podría quedarse congelada.
Si guardáramos SUBMITTED después del clic, existe una pequeña ventana
donde el dinero podría haber sido enviado pero nuestra base de datos
todavía pensaría que no.
Después de reiniciar, el bot podría volver a intentarlo.
Persistiendo primero el estado crítico, el sistema sabe:
Este pago pudo haber sido enviado. NO repetir automáticamente. Esto proporciona una barrera de idempotencia alrededor de una interfaz
que originalmente no ofrece ninguna.
Recuperación después de reiniciar el bot
Persistir estados también permite distinguir dos situaciones
completamente diferentes después de un reinicio.
Una operación que estaba simplemente preparando datos:
PROCESSING puede volver a evaluarse de forma segura.
Una operación que alcanzó:
SUBMITTED no puede tratarse igual.
El dinero podría haber salido.
Por eso el arranque del sistema también contiene controles de seguridad.
Si encuentra una operación en un estado crítico, el bot puede bloquear
el procesamiento automático en lugar de continuar como si nada hubiera
ocurrido.
La filosofía es sencilla:
Antes de enviar dinero: podemos reconstruir el proceso. Después de posiblemente enviar dinero: no podemos adivinar. Conciliación manual para pagos ambiguos
Automatizar no significa eliminar al operador de absolutamente todas las
situaciones.
Hay casos donde el banco simplemente no proporciona suficiente
información para tomar una decisión segura.
Cuando una operación queda en PAYMENT_UNKNOWN, el operador puede
verificar manualmente el resultado en Banco de Venezuela.
Si confirma que el dinero realmente fue enviado, el sistema puede
continuar con las etapas posteriores sin repetir el pago bancario.
Si no puede confirmarlo, la operación permanece sin marcar como pagada.
Y si decide no resolverla todavía, la cola permanece protegida.
Esto nos permite mantener una regla fundamental:
La incertidumbre nunca provoca otro pago automático. El human-in-the-loop no está sustituyendo la automatización normal.
Está actuando únicamente como mecanismo de seguridad cuando la
información disponible no permite tomar una decisión financiera
confiable.
El comprobante BDV forma parte de la transacción
Una transferencia exitosa tampoco termina simplemente cuando BDV dice
que fue realizada.
Necesitamos asociar ese pago con su orden correspondiente de Binance
P2P.
Para cada operación podemos conservar información como:
Binance Order ID Tipo de pago Monto Referencia BDV Comprobante Estado de procesamiento Cuando BDV muestra el comprobante final, el sistema verifica sus datos y
extrae la referencia de la operación.
El comprobante puede guardarse y enviarse posteriormente al chat
correspondiente de Binance P2P.
Después se ejecuta la etapa de Mark Paid.
El orden es importante:
Pago BDV confirmado ↓ Comprobante ↓ Entrega / Chat ↓ Mark Paid Si Binance falla después de que BDV ya realizó la transferencia, nunca
volvemos a ejecutar el pago bancario para solucionar el problema de
Binance.
Son dos dominios separados.
Fallo bancario ≠ Fallo de entrega a Binance Separarlos evita que un error secundario termine provocando un pago
duplicado.
Recuperar la aplicación Banco de Venezuela de forma segura
Automatizar Android introduce estados que normalmente no existen cuando
trabajamos con una API.
BDV puede aparecer en:
HOME LOGIN REVIEW CONFIRMATION PROCESSING RECEIPT ERROR La recuperación no puede consistir simplemente en presionar Back
varias veces hasta llegar al inicio.
En una pantalla financiera, una acción aparentemente inocente puede
tener consecuencias diferentes dependiendo del estado actual.
Por eso la recuperación también debe conocer el estado persistido de la
transacción.
El sistema primero determina:
¿El pago todavía no fue enviado? o:
¿El pago ya pudo haber sido enviado? Solo entonces decide qué acciones son seguras.
La automatización de interfaces financieras debe ser conservadora
incluso cuando eso significa detenerse.
Pago Móvil y transferencias BDV: dos flujos, una misma política de seguridad
Aunque Pago Móvil y las transferencias bancarias de Banco de
Venezuela utilizan pantallas y datos diferentes, comparten las mismas
reglas fundamentales.
Validar datos ↓ Verificar pantalla BDV ↓ Verificar Binance ↓ Persistir estado ↓ Enviar pago ↓ Verificar resultado ↓ Guardar comprobante ↓ Notificar Binance Esto evita construir dos automatizaciones completamente independientes
con políticas de seguridad diferentes.
La navegación puede cambiar.
La lógica financiera no debería hacerlo.
Probando múltiples órdenes de Binance P2P
Una prueba con un solo pago demuestra muy poco sobre un sistema de
automatización financiera.
El comportamiento interesante aparece cuando llegan varias órdenes.
Durante las pruebas procesamos múltiples operaciones de forma secuencial
para comprobar:
Orden #1 ↓ Pago ↓ Comprobante ↓ Binance ↓ HOME ↓ Orden #2 ↓ Pago ↓ ... Estas pruebas permiten descubrir problemas que difícilmente aparecen en
un demo aislado:
- órdenes simultáneas;
- datos bancarios inválidos;
- cambios de estado en Binance;
- recuperación después de reinicios;
- diferencias entre Pago Móvil y transferencias;
- comprobantes con pequeñas variaciones;
- operaciones bancarias que tardan demasiado;
- errores después de que el dinero ya fue enviado.
Una demostración exitosa demuestra que ese caso funcionó.
No demuestra cómo se comportará el sistema después de cientos de
operaciones y diferentes estados externos.
Velocidad vs. seguridad en automatización de pagos
Cuando existen muchas órdenes pendientes es tentador intentar eliminar
cada espera.
Pero no todas las esperas pertenecen al bot.
Hay tiempo consumido por:
Binance Android Banco de Venezuela Red Procesamiento bancario Podemos optimizar nuestra parte del flujo.
Lo que no debemos hacer es reducir verificaciones financieras únicamente
para ahorrar algunos segundos.
En este proyecto priorizamos:
1. No pagar una orden incorrecta 2. No pagar dos veces 3. Poder recuperar el estado 4. Verificar el resultado 5. Después, optimizar velocidad Para un bot de Binance P2P que mueve dinero real, ese orden importa.
Lo que aprendimos construyendo automatización BDV sin una API bancaria
Inicialmente, el proyecto parecía ser principalmente un problema de
automatización Android.
Terminó siendo mucho más un problema de diseño de sistemas de pago.
Las lecciones más importantes no fueron cómo encontrar un botón con
Android automation.
Fueron:
Persistir el estado antes de cruzar un punto irreversible.
Nunca interpretar UNKNOWN como FAILED.
No volver a ejecutar automáticamente una operación que pudo haber
movido dinero.
Verificar nuevamente Binance inmediatamente antes del pago.
Validar lo que Banco de Venezuela realmente muestra, no lo que
esperamos que muestre.
Separar el pago bancario de las etapas posteriores de Binance.
No intentar adivinar datos bancarios incompletos.
Diseñar primero el comportamiento ante fallos y después el happy
path.
Incluso pequeños detalles de interfaz terminaron siendo importantes.
Una diferencia entre:
Transferencias a terceros BDV y:
Transferencias a terceros fue suficiente para enseñarnos nuevamente que una aplicación móvil no es
una API estable.
El software tiene que adaptarse a esa realidad sin sacrificar las
verificaciones que protegen el dinero.
De un experimento de automatización a un bot de Binance P2P para Venezuela
Esta arquitectura terminó convirtiéndose en la base de nuestro Binance
P2P Banco de Venezuela Bot: un sistema diseñado para automatizar
órdenes BUY de Binance P2P mediante Pago Móvil BDV y transferencias
bancarias, incluyendo validación de datos, cola de pagos, verificación
de comprobantes, referencias de operación, entrega del comprobante y
confirmación del pago en Binance.
El objetivo nunca fue construir un script que simplemente presionara
botones.
El objetivo fue construir una capa de automatización capaz de operar
entre Binance P2P y Banco de Venezuela sin olvidar una propiedad
fundamental de cualquier sistema financiero:
Cuando no sabemos con certeza si el dinero fue enviado, la respuesta
correcta nunca es enviarlo otra vez.
Más información técnica sobre el proyecto:
Binance P2P Banco de Venezuela Bot -
https://py-dev.top/es/software-de-aplicaciones/binance-p2p-banco-de-venezuela-bot
