Binance Smart Chain API para Pagos en BNB y BEP-20
Envía y recibe BNB y tokens BEP-20 mediante una única API REST. Crea direcciones de depósito, recibe webhooks firmados con HMAC, y lánzate en BSC sin ejecutar un node.
La Binance Smart Chain API de Chaingateway mueve BNB y tokens BEP-20 mediante llamadas REST sencillas. Tu backend crea direcciones de depósito por HTTPS y envía tokens con una única solicitud POST. Cuando un cliente paga, un webhook llega a tu servidor, sincronizado con los bloques de menos de un segundo de BSC. No hay ningún nodo que ejecutar ni ninguna librería web3 que instalar: la autenticación es un Bearer token en la cabecera Authorization, y cada respuesta es JSON.
El registro toma un minuto. La prueba dura 7 días, no cuesta nada y no pide KYC. Crea una API key y envía tu primera transacción de testnet hoy mismo.
Todo lo que necesitas para construir en Binance Smart Chain
Webhooks (IPN)
BSC produce un bloque aproximadamente cada 0,75 segundos desde que el hardfork Maxwell entró en vigor el 30 de junio de 2025, y las notificaciones de depósito siguen el mismo ritmo. Cuando una transferencia BEP-20 llega a una de tus direcciones, Chaingateway llama a tu endpoint con el payload decodificado. Fija un secreto personal en tu perfil y cada llamada llevará una cabecera X-Signature para que puedas verificar al remitente. Si tu endpoint estuvo caído, la API lista las entregas fallidas y se reenvían con una llamada por notificación.
Transacciones sencillas
Una solicitud POST envía BNB (POST /api/v2/bsc/transactions) o cualquier token BEP-20 (POST /api/v2/bsc/transactions/bep20). Gas y nonce son campos opcionales de la solicitud que la API rellena, así que nunca ajustas a mano valores en gwei ni sigues nonces entre pagos concurrentes.
Manejo seguro de direcciones
BSC usa el mismo formato de dirección 0x y el mismo checksum EIP-55 que Ethereum. La API valida cada dirección antes de construir una transacción, y la arquitectura es non-custodial: tus keys siguen siendo tuyas. Si ya gestionas pares de keys, regístralas con POST /api/v2/bsc/addresses/import.
Consultas decodificadas
Los logs en bruto de BSC son blobs hexadecimales. El endpoint de transacción decodificada de Chaingateway devuelve en su lugar JSON legible — remitente, destinatario e importe como campos planos — y los payloads de webhook llegan decodificados de la misma forma.
Una API REST, no otro endpoint RPC
Si buscaste "Binance Smart Chain RPC", probablemente esperabas una URL de nodo. La documentación oficial en docs.bnbchain.org lista endpoints JSON-RPC públicos, y funcionan. Pero te dejan la parte difícil a ti. Una conexión RPC en bruto entiende eth_call y eth_sendRawTransaction; la codificación ABI y la gestión de nonces ocurren en tu código, y también el manejo de keys. Los endpoints públicos además limitan agresivamente bajo carga, que es justo cuando más los necesita tu sistema de pagos.
Chaingateway se sitúa una capa más arriba. Le dices a la API qué token enviar, cuánto y a quién. Ella construye la transacción y la transmite a la red; cada transacción creada mediante la API se lista, hash incluido, bajo GET /api/v2/bsc/transactions, así que puedes enlazar a tus usuarios directamente con BscScan.
La disyuntiva es honesta: si necesitas llamadas de contrato arbitrarias o consultas de profundidad archive, ejecuta un nodo o usa un proveedor de RPC. Si necesitas pagos, es decir, depósitos entrantes y pagos salientes, la capa REST elimina la mayor parte del código que de otro modo tendrías que escribir y mantener tú mismo.
Referencia de endpoints de BSC
La documentación oficial de BNB Chain responde a la pregunta del RPC con una lista de quince métodos JSON-RPC y una URL de nodo público. Esa lista describe el protocolo. Una integración de pagos necesita algo más corto. Cinco endpoints cubren todo el ciclo en Chaingateway:
| Método | Endpoint | Qué hace |
|---|---|---|
POST | /api/v2/bsc/addresses/import | Registra una private key existente para que la API pueda enviar desde esa dirección |
POST | /api/v2/bsc/transactions | Construye, firma y transmite una transferencia nativa de BNB |
POST | /api/v2/bsc/transactions/bep20 | Construye, firma y transmite una transferencia de token BEP-20 |
GET | /api/v2/bsc/webhooks/notifications | Lista cada notificación de depósito que la API ha enviado a tu servidor |
GET | /api/account | Comprueba el estado de tu cuenta y plan |
Cada uno de ellos acepta la cabecera X-Network: testnet para ensayos, y cada solicitud se autentica con el mismo Bearer token. Los esquemas exactos de solicitud y respuesta están en la referencia de la API.
Método JSON-RPC frente a una sola llamada REST
Aquí está la misma tabla desde el lado del integrador: qué te cuesta una tarea contra un nodo en bruto, y qué te cuesta contra la capa REST.
| Trabajo a hacer | JSON-RPC en bruto | Chaingateway |
|---|---|---|
| Enviar 25 USDT | eth_gasPrice, eth_getTransactionCount, eth_estimateGas, eth_sendRawTransaction, más codificación ABI y firma de transacción en tu propio código |
Un POST /api/v2/bsc/transactions/bep20 |
| Detectar un depósito | Hacer polling a eth_blockNumber, escanear eth_getLogs en busca de eventos Transfer, decodificar topics y ajustar por decimales del token |
Llega un POST de webhook a tu servidor |
| Auditar historial de depósitos | Construir y operar tu propio indexador | GET /api/v2/bsc/webhooks/notifications |
Para hacerte una idea de la diferencia, así es como se ve hablar con un nodo público de BSC:
curl -X POST https://bsc-dataseed.bnbchain.org \
-H "Content-Type: application/json" \
-d '{"jsonrpc":"2.0","method":"eth_blockNumber","params":[],"id":1}'
La respuesta es una cadena hex. Todo lo que viene después, desde convertir 0x30bf8d3 en un número hasta obtener logs y mapear importes en bruto contra los decimales del token, es código que tú escribes y depuras. Multiplica eso por cada método que necesites y terminas con un pequeño proyecto de middleware interno. La llamada REST se salta el middleware porque ella misma es el middleware.
BSC en cifras
BSC ha apuntado a bloques de 0,75 segundos desde el hardfork Maxwell del 30 de junio de 2025, y el gas se ha mantenido barato, típicamente entre 0,1 y 1 gwei según el tracker de BscScan. Una transferencia BEP-20 estándar consume entre 50.000 y 65.000 de gas, lo cual a esos precios equivale a una fracción de centavo.
Los datos de la chain envejecen rápido, así que aquí están las cifras completas con fechas asociadas. A principios de julio de 2026:
El objetivo de intervalo de bloque es de 0,75 segundos. El hardfork Maxwell lo fijó el 30 de junio de 2025, y BscScan midió un promedio de unos 0,8 segundos poco después de la activación. Antes en 2025, el hardfork Lorentz ya había reducido a la mitad el antiguo intervalo de 3 segundos hasta 1,5 segundos, así que BSC cuadruplicó su velocidad de bloque en un solo año.
El gas es barato y se ha mantenido barato. El tracker de gas de BscScan se ha mantenido en el rango de 0,1 a 1 gwei durante 2026, con un promedio diario de alrededor de 0,63 gwei en marzo de 2026. Una transferencia BEP-20 estándar consume del orden de 50.000 a 65.000 de gas, lo cual a esos precios equivale aproximadamente a 0,00004 BNB. Comprueba tú mismo el precio actual de BNB antes de cotizar comisiones a tus clientes, pero el resultado se ha mantenido en centavos bajos durante años.
Para una página de checkout, la consecuencia práctica es esta: la transferencia de USDT de un cliente está en un bloque en aproximadamente un segundo, y tras unos pocos bloques adicionales, unos segundos en total, puedes acreditar el pedido. Compáralo con Ethereum mainnet, donde solo un slot ya tarda 12 segundos.
Envía y recibe cualquier token en BSC, incluso el tuyo
Cada contrato BEP-20 estándar funciona. USDT, USDC y DAI funcionan de fábrica, con importes en unidades de token en lugar de unidades base en bruto. Si has lanzado tu propio token, pasa su contract address al mismo endpoint y se comportará como cualquier otro. Como la API es idéntica entre chains, el código que escribes para BSC también se ejecuta contra Ethereum, Polygon o Arbitrum en cuanto cambies el segmento de chain en la URL.
Por qué los desarrolladores eligen Binance Smart Chain
Las comisiones en BSC quedan muy por debajo de Ethereum mainnet, lo cual importa cuando procesas muchos pagos pequeños en lugar de unos pocos grandes. Los tiempos de bloque por debajo del segundo mantienen ágiles los flujos de checkout. El ecosistema DeFi en torno a PancakeSwap da a los tokens BEP-20 una liquidez profunda, y la red ha soportado un uso diario activo alto durante años, así que sus modos de fallo son bien conocidos y sus herramientas están maduras.
Quickstart: envía USDT (BEP-20) en cuatro lenguajes
Todos los ejemplos llaman a POST /api/v2/bsc/transactions/bep20 con un Bearer token. El contract address siguiente es el de USDT en BSC (0x55d398326f99059fF775485246999027B3197955); password es la contraseña de la wallet protegida de la dirección remitente. El esquema exacto de solicitud está en la referencia de la API. Para probar sin fondos reales, añade la cabecera X-Network: testnet.
cURL
curl -X POST https://app.chaingateway.io/api/v2/bsc/transactions/bep20 \
-H "Authorization: Bearer $CHAINGATEWAY_API_KEY" \
-H "Content-Type: application/json" \
-d '{
"contractaddress": "0x55d398326f99059fF775485246999027B3197955",
"from": "0xYourSenderAddress",
"to": "0xRecipientAddress",
"amount": 25.0,
"password": "wallet-password"
}'Esa es la solicitud de transferencia completa — crea una cuenta y ejecútala primero en la testnet de BSC.
Cómo llegan los depósitos BEP-20 a tu backend
Una integración de pagos en BSC sigue un ciclo:
- Da a cada usuario una dirección de depósito. Si tu sistema ya gestiona keys, regístralas con
POST /api/v2/bsc/addresses/import. - Añade un webhook a la dirección. La configuración toma unos minutos y se describe en la guía de webhooks.
- El cliente envía USDT a la dirección. La transferencia entra en un bloque en aproximadamente un segundo, y Chaingateway envía por POST el evento decodificado a tu endpoint.
- Tu servidor verifica la firma HMAC y acredita la cuenta. Ese es todo el flujo.
En producción, tres detalles separan una demo de un sistema que puedes dejar en paz.
El primero es el mapeo de direcciones. Guarda una fila por cliente o por pedido: tu ID interno, la dirección de depósito, la fecha de creación. Cuando llega un webhook, la dirección destinataria en el payload es tu clave de búsqueda. Un índice único en la columna de dirección garantiza que un depósito nunca pueda acreditarse a dos clientes, sin importar cómo cambie el código a su alrededor.
El segundo es la idempotencia. La entrega no es exactamente-una-vez: una notificación fallida que reenvías a través de la API llega de nuevo completa. Registra el hash de transacción de cada depósito procesado con una restricción única, y deja que la base de datos rechace duplicados. Una lógica de acreditación que sobrevive a que el mismo evento llegue tres veces es la diferencia entre un mecanismo de reenvío que te protege y uno que paga doble.
El tercero es una política de confirmación. Un webhook te dice que la transferencia está en un bloque. Con bloques de 0,75 segundos, otros diez bloques llegan en bastante menos de diez segundos, así que esperar un pequeño margen de seguridad cuesta casi nada en experiencia de usuario. Para una compra digital de 5 USDT, acreditar tras la notificación es una decisión de negocio razonable. Para un depósito de 50.000 USDT, espera unos segundos más y vuelve a comprobar la transacción (GET /api/v2/bsc/transactions/{txid}) antes de liberar nada.
Los depósitos también se acumulan en muchas direcciones a lo largo del tiempo. La respuesta habitual es una consolidación periódica: un trabajo programado que envía los saldos acumulados desde las direcciones de depósito hacia tu wallet de tesorería, usando la misma llamada POST /api/v2/bsc/transactions/bep20 con la dirección de depósito en el campo from. Cada dirección que consolida necesita una pizca de BNB para el gas, que a precios por debajo del gwei es un error de redondeo.
Si tu endpoint fue inalcanzable, las entregas perdidas no se han ido: GET /api/v2/bsc/webhooks/notifications/failed las lista, y POST /api/v2/bsc/webhooks/notifications/{id}/retry reenvía cada una. Para conciliación, también puedes listar todo lo que la API te ha enviado:
curl https://app.chaingateway.io/api/v2/bsc/webhooks/notifications \
-H "Authorization: Bearer $CHAINGATEWAY_API_KEY"
Ese único endpoint convierte "¿nos perdimos un depósito?" de un ticket de soporte en una comparación contra tu propia base de datos.
Pagos: la otra mitad del ciclo
Los retiros merecen el mismo cuidado que los depósitos, porque un error aquí envía dinero en lugar de perderlo.
Valida antes de enviar
El flujo empieza antes de la llamada a la API. Valida la dirección de destino en el momento en que el usuario la envía: longitud correcta, prefijo 0x, y el checksum EIP-55 si hay letras en mayúscula y minúscula mezcladas. Un fallo de checksum significa un error tipográfico, y detectarlo en el formulario no cuesta nada, mientras que detectarlo después de transmitir es imposible. La API rechaza direcciones malformadas antes de construir la transacción, pero la comprobación de checksum te toca a ti ejecutarla — y para cuando la API responde, el usuario ya se ha ido de la página.
Rastrea cada pago en tu base de datos
Escribe el pago en tu base de datos antes de enviarlo. Una fila por pago, con una columna de estado: queued, sent, confirmed. Un worker recoge las filas en cola, hace exactamente una llamada POST /api/v2/bsc/transactions/bep20 por fila, y guarda la respuesta de la API junto a ella. El hash de transacción — tu recibo — aparece en GET /api/v2/bsc/transactions, la lista de todo lo creado mediante la API. Muéstraselo al usuario como un enlace de BscScan y podrá ver cómo se confirma su propio retiro, lo cual elimina discretamente el ticket de soporte más común de la categoría.
Gestión de timeouts
El caso de fallo que importa es el timeout. Si tu llamada a la API hace timeout, no sabes si la transferencia salió. No reintentes a ciegas. Comprueba primero GET /api/v2/bsc/transactions y tus propios registros, y solo reenvía cuando estés seguro de que nada se transmitió. Como los pagos salen de una hot wallet, mantén un colchón de BNB en la dirección remitente para el gas; a los precios actuales de BSC, una pequeña recarga cubre miles de transferencias, así que es una tarea mensual más que un riesgo operativo.
Prueba primero en la testnet de BSC
Cada endpoint de esta página se ejecuta contra la testnet de BSC cuando añades una cabecera:
X-Network: testnet
Sin segunda cuenta, sin API key separada, sin cambios de código más allá de la cabecera. El BNB de testnet sale gratis del faucet oficial de BNB Chain, así que puedes ensayar todo el ciclo, desde la creación de direcciones pasando por el webhook de depósito hasta el pago, sin fondos reales. Los formatos de dirección y la mecánica de transacción son idénticos a mainnet.
El ensayo que merece la pena es el feo: envía un depósito mientras tu endpoint de webhook está apagado, vuelve a encenderlo, luego reenvía la entrega desde la lista de fallidos (POST /api/v2/bsc/webhooks/notifications/{id}/retry) y observa cómo llega. Confirma tu manejo de idempotencia reproduciendo una notificación contra tu propio endpoint. Diez minutos de pruebas deliberadas de fallo en testnet ahorran una revisión de incidente en mainnet. Cuando todo se sostenga, elimina la cabecera y el mismo código estará en producción.
Seguridad de webhooks en la práctica
Un endpoint de webhook es una puerta hacia tu sistema de contabilidad, así que trátalo como tal.
Verifica la firma antes de analizar cualquier otra cosa. Fija un secreto personal en la configuración de tu perfil; a partir de entonces Chaingateway envía una cabecera X-Signature con cada notificación — base64 de un HMAC-SHA256 sobre el txid del payload, con ese secreto como key. Tu servidor lo recalcula a partir del txid recibido y lo compara en tiempo constante. Una solicitud que falla la comprobación recibe un 4xx y ningún procesamiento adicional, sin importar lo plausible que parezca su payload. La mecánica, código de verificación incluido, está en la guía de webhooks.
Un segundo cierre, independiente, protege la otra dirección: en el panel de la cuenta puedes restringir tu API key a las direcciones IP de tus propios servidores. Esa lista blanca protege el acceso a la API — una key filtrada no mueve nada desde ningún otro sitio — no el endpoint de webhook, así que complementa la firma en lugar de reemplazarla.
El reenvío es el ataque que el HMAC por sí solo no detiene, ya que una notificación válida grabada sigue siendo válida. Tu restricción de idempotencia cierra ese hueco: un hash de transacción que ya se acreditó se reconoce y se ignora. Sirve el endpoint solo por HTTPS, y mantén la URL del webhook libre de secretos, porque las URLs acaban en registros de sistemas que no controlas.
Cuando fallan las solicitudes
Toda integración acaba viendo errores, y la API los reporta como códigos de estado HTTP normales, así que tus patrones de manejo de errores existentes aplican.
Un 401 significa que el Bearer token falta, ha caducado o está mal; comprueba la cabecera Authorization y la key en tu panel. Los fallos de validación en el rango 4xx, como una dirección malformada o un campo ausente, llegan con un cuerpo JSON que explica qué corregir. No reintentes estos: la misma solicitud fallará de la misma forma hasta que cambies el payload.
Los límites de solicitud y de dirección dependen de tu plan; si te topas con ellos habitualmente, la página de precios lista planes con límites más altos. Los errores 5xx del lado del servidor y los timeouts son seguros de reintentar para solicitudes de lectura. Para envíos, aplica la regla de timeout de la sección de pagos: verifica que nada se transmitió antes de volver a enviar.
Registra el cuerpo completo de la respuesta junto a tu propio registro de solicitud. Cuando algo necesita atención de soporte, ese emparejamiento responde la mayoría de las preguntas antes de que se hagan. Los códigos de estado y esquemas de error de cada endpoint están documentados en la referencia de la API.
Dejar tu propio nodo de BSC
Muchos equipos ejecutan un full node de BSC para exactamente un propósito: observar depósitos y transmitir pagos. Ese nodo cuesta dinero real y atención. Los requisitos de almacenamiento se miden en terabytes de NVMe, la sincronización inicial tarda días sin un snapshot, y solo 2025 trajo dos hardforks, Lorentz y Maxwell, cada uno una actualización de cliente obligatoria con fecha límite. Te pierdes uno y tu nodo deja de seguir la chain, lo cual para un sistema de pagos significa que los depósitos dejan de llegar en silencio.
Si el nodo existe solo para pagos, la ruta de migración es corta. Importa tus keys existentes con POST /api/v2/bsc/addresses/import, reemplaza tu bucle de polling a eth_getLogs con notificaciones de webhook, y apunta el código de pagos a POST /api/v2/bsc/transactions/bep20. Ejecuta ambos sistemas en paralelo durante una semana y compara los resultados; la lista de notificaciones convierte esa comparación en una consulta en lugar de un proyecto. Luego da de baja el nodo y recupera el presupuesto de hardware.
Si quieres mantener un nodo, o estás decidiendo si construir uno desde el principio, nuestra guía de configuración de un nodo de Binance Smart Chain recorre honestamente el hardware, la sincronización y el mantenimiento. Los dos enfoques también se combinan: algunos equipos mantienen un nodo para consultas archive y llamadas de contrato mientras enrutan el tráfico de pagos a través de la API, porque la capa de webhooks de la API es la parte genuinamente tediosa de reconstruir.
Construido para cada caso de uso
La mayoría de los equipos en los endpoints de BSC de Chaingateway ejecutan uno de dos patrones. El primero es aceptar pagos: una tienda o SaaS genera una dirección de depósito por pedido, espera el webhook y envía el producto, con liquidación en segundos en lugar de días bancarios. El segundo son las operaciones de wallet a escala: exchanges y plataformas que observan depósitos y procesan retiros a través de miles de direcciones de usuario, todo mediante los mismos pocos endpoints.
Los mismos bloques de construcción cubren lanzamientos de tokens (airdrops y pagos de vesting programados como transferencias BEP-20), transferencias transfronterizas donde una transferencia bancaria tardaría días, pagos recurrentes para facturación de suscripciones, y productos DeFi que necesitan ver transacciones en el momento en que confirman.
Integración en tres pasos
Obtén tu API key. Regístrate y la key está en tu panel de inmediato. La prueba de 7 días empieza sin KYC.
Haz tu primera solicitud. El quickstart te lleva desde el registro hasta una primera transacción.
Configura webhooks y sal a producción. Los depósitos se envían a tu servidor en lugar de que tú hagas polling por ellos — la guía de webhooks cubre la configuración y la verificación de firma — luego elimina la cabecera X-Network: testnet y el mismo código se ejecuta contra mainnet.
Precios
Los planes y sus límites están listados en la página de precios. Toda cuenta nueva empieza con la prueba gratuita de 7 días, así que puedes terminar toda la integración de BSC antes de pagar nada.
Qué funciona en cada chain
BSC sigue el mismo patrón de solicitud que Ethereum, con BEP-20 en lugar de ERC-20. La tabla siguiente la sitúa junto a las otras seis chains que cubre la API.
| Chain | Direcciones | Transferencias de tokens | Webhooks de depósito |
|---|---|---|---|
| Bitcoin | POST /api/v2/bitcoin/wallets/{wallet}/addresses | — (sin estándar de token) | GET /api/v2/bitcoin/webhooks/notifications |
| Ethereum | POST /api/v2/ethereum/addresses/import | ERC-20: POST /api/v2/ethereum/transactions/erc20 | GET /api/v2/ethereum/webhooks/notifications |
| TRON | POST /api/v2/tron/addresses/import | TRC-20 y TRC-10: POST /api/v2/tron/transactions/trc20 y .../trc10 | GET /api/v2/tron/webhooks/notifications |
| Solana | POST /api/v2/solana/addresses | SPL: POST /api/v2/solana/transactions/SPL | — |
| BNB Smart Chain | POST /api/v2/bsc/addresses/import | BEP-20: POST /api/v2/bsc/transactions/bep20 | GET /api/v2/bsc/webhooks/notifications |
| Polygon | POST /api/v2/polygon/addresses/import | ERC-20: POST /api/v2/polygon/transactions/erc20 | GET /api/v2/polygon/webhooks/notifications |
| Arbitrum | POST /api/v2/arbitrum/addresses/import | ERC-20: POST /api/v2/arbitrum/transactions/erc20 | GET /api/v2/arbitrum/webhooks/notifications |
Dos notas al pie para leer bien la tabla. Primero: TRON es la integración más profunda de la plataforma. Más allá de las rutas anteriores, la documentación cubre staking (POST /api/v2/tron/freeze y /delegate), parámetros de la chain, y un par de auto-firma — /transactions/trc20/build para construir una transacción y /transactions/broadcast para enviar una que hayas firmado localmente. Si tu equipo de cumplimiento insiste en que las private keys nunca salgan de tus servidores, ese patrón de construir y transmitir es tu vía de entrada.
Segundo: un guion significa que la documentación actual no recoge una ruta v2 para esa celda, no que la red sea de segunda categoría. Bitcoin no tiene estándar de token, de ahí la celda de token vacía — el BTC nativo funciona con su propio modelo de wallet en su lugar: crea una wallet cifrada con contraseña con POST /api/v2/bitcoin/wallets, deriva direcciones de depósito bajo ella, y envía con POST /api/v2/bitcoin/transactions. La documentación de Solana cubre creación de direcciones, transferencias de SOL y SPL, y consultas de saldo y bloque, pero aún sin webhooks. Para cualquier cosa no listada aquí, la referencia de la API tiene el estado actual.
Preguntas frecuentes
¿Listo para integrar Binance Smart Chain?
Crea tu cuenta, copia la API key y envía una transacción de testnet en los próximos diez minutos. La referencia completa de endpoints está en /docs/, y el portal para desarrolladores reúne tutoriales para los flujos de pago más comunes.