Bangladés: bKash, Nagad y una cuenta bancaria no son intercambiables

La promesa de «conectar bKash y Nagad con una sola API» no dice nada sobre a qué cuentas llegará el dinero. Para el procesamiento en Bangladés, la pregunta principal empieza antes de la API: ¿el receptor actúa como comercio, agente, titular de una billetera personal o intermediario de pagos? Cada uno de estos roles tiene su propia finalidad, condiciones de acceso y restricciones. El número de teléfono que el usuario conoce todavía no explica la estructura legal y contable.

bKash y Nagad figuran entre los servicios financieros móviles locales más visibles. Aquí no se clasifican por popularidad: el número de registros, de usuarios activos y de pagos comerciales son indicadores distintos. Para elegir una integración es más importante verificar el producto concreto disponible, su contrato y la posibilidad de reconstruir el recorrido del dinero sin depender de la palabra del intermediario.

Cuatro roles detrás de una pantalla parecida

Una transferencia personal, un pago comercial, la operación de un agente con efectivo y un pago de una empresa son operaciones distintas. Bangladesh Bank describe por separado P2P, P2B y B2P entre los servicios MFS nacionales. Por lo tanto, la frase «la billetera recibe transferencias» no demuestra que esa cuenta esté autorizada para recaudar de forma masiva los ingresos de otras empresas. Se necesita un rol confirmado, no solo un botón que funciona.

El formulario de alta de bKash Merchant solicita datos de la tienda y de la persona de contacto, información del NID, de la licencia comercial y de la cuenta bancaria. Es una solicitud sujeta a verificación posterior, no una admisión automática. Por separado existe la Personal Retail Account, pensada para pequeños negocios minoristas y de f-commerce. El nombre Personal confunde con facilidad: el operador clasifica expresamente la PRA como cuenta de negocio.

La página publicada de la PRA indica requisitos propios de identidad y de SIM, así como un límite de cobro de 30 000 BDT por operación y por día, y de 500 000 BDT al mes. Estas cifras corresponden solo a ese producto, verificado el 12 de octubre de 2026, y no describen todo el servicio. Antes de firmar el contrato hay que obtener la tabla vigente para la categoría elegida. No se pueden usar los límites de un tipo de cuenta como promesa para otro.

Qué preguntar sobre Nagad si las ventas van por delante de la documentación

No se pueden trasladar a Nagad los estados, la refund API y las reglas de su competidor solo porque ambos productos parecen billeteras móviles. En la página pública de Nagad con límites que se revisó no fue posible obtener una tabla numérica completa. Por eso aquí no se indica a propósito un límite actual universal. Es un límite concreto de la verificación, no una afirmación de que no existan límites.

Para una propuesta comercial, solicite la entidad jurídica del proveedor, el nombre exacto del producto merchant, las condiciones de aceptación, un modelo de informe, los límites por tipo de operación y la versión vigente de la documentación de integración. Si se usa un agregador, averigüe quién es parte del contrato con Nagad y quién responde por un estado erróneo. Una clave de demostración o una librería no oficial no prueban que production esté disponible para su negocio.

Una prueba útil para el proveedor: mostrar un pago de prueba autorizado, su reference original, el registro del receptor y la línea de liquidación. Después, repetir el procedimiento con una cancelación antes del pago y con una devolución posterior. La falta de una respuesta documentada no se rellena con la promesa de que «normalmente funciona»; esa ruta queda fuera del lanzamiento.

Datos de pago y pruebas: el número de teléfono no basta

En el registro propio conviene separar el identificador del pedido, el intento, el proveedor, el tipo de operación, la cuenta de destino, el importe en BDT, la hora y la reference del evento financiero. La prueba es la confirmación del proveedor que presta el servicio o del banco. La captura de pantalla del pagador ayuda a encontrar la operación, pero no debe disparar por sí sola la entrega del producto ni el aumento del saldo interno.

SSLCOMMERZ ofrece un ejemplo de modelo de pasarela documentado: tran_id lo asigna la tienda, val_id se usa para la verificación y bank_tran_id corresponde al lado bancario. VALIDATED significa una nueva validación de una operación exitosa, no un segundo pago. Refund tiene sus propios refund_trans_id y refund_ref_id; crear con éxito la solicitud no equivale al estado refunded. Son campos propios de SSLCOMMERZ, no la especificación nativa de bKash o Nagad. Documentación de la pasarela.

Supongamos que dos compradores enviaron importes idénticos en el mismo minuto. Si el sistema guarda solo el teléfono, el importe y la captura, el emparejamiento es ambiguo. Un diseño correcto define de antemano los identificadores confirmados disponibles, las reglas de coincidencia parcial y la cola de revisión manual. El operador no debe «elegir el pedido que más se parezca» para mejorar el indicador de conversión.

El banco es otra capa, no una billetera grande

Bangladesh Bank distingue BEFTN, NPSB y RTGS. BEFTN está asociado al intercambio por lotes, NPSB a la conmutación interbancaria de las operaciones correspondientes y RTGS a la liquidación bruta en tiempo real dentro del horario de operación establecido. No se puede prometer el mismo plazo para todos los pagos bancarios. Se necesitan el banco elegido, el canal, el calendario de procesamiento y las reglas del tipo de cuenta concreto.

Para la liquidación al comercio, pregunte dónde termina el pago MFS y dónde empieza el retiro de fondos al banco. La comisión de aceptación, el retiro, la devolución y una posible conversión son líneas distintas de la economía del servicio. Si el comprador pagó 1 000 BDT, un ingreso bancario menor no debe clasificarse automáticamente como pago insuficiente: primero revise las retenciones contractuales. El error inverso es contabilizar el importe completo por segunda vez cuando llega el lote de liquidación de pagos ya registrados.

Una actividad prohibida no se vuelve comercial por cambiarle el nombre

El aviso oficial de bKash enumera expresamente los juegos de azar y la participación en apuestas en línea o su organización entre las categorías prohibidas. El operador prevé la suspensión del servicio y medidas legales. Por eso, la propuesta de recibir ese tráfico en un «merchant normal» no gana legitimidad gracias a la licencia extranjera del cliente.

Lo mismo vale para la gestión de incidentes. Cambiar la finalidad declarada, cobrar a través de la cuenta de otra persona o pasar a transferencias personales no corrige el incumplimiento contractual. Para un negocio legal, la solidez se construye con un producto acordado, una cadena de receptores verificada, acceso a los informes y un responsable claro de cada pago pendiente. Son estas cosas, y no la cantidad de logotipos en la caja, las que determinan si una integración es adecuada.