Pasarela de pagos cripto con API REST: checkout a tu medida

Por qué cuesta tanto encontrar una API de pagos cripto seria

Si operas un carrito a medida, un marketplace, un sistema de facturación SaaS o cualquier checkout que tu equipo construyó, los plugins no te sirven. Necesitas una API: algo que tu backend llame para crear un cobro, y algo que te llame de vuelta — de forma confiable y verificable — cuando llegue el dinero.

Busca "pasarela de pagos cripto API" y encontrarás dos montones frustrantes. El primero: pasarelas custodiales con una API encima. La superficie REST parece familiar, pero cada pago cae en el saldo del proveedor, y tu dinero real llega después — tras su calendario de payouts, su revisión de riesgo, su umbral de retiro. Integraste una API; recibiste un intermediario con forma de banco.

El segundo montón: infraestructura de cadena en crudo. Proveedores de nodos, SDKs de wallets y tutoriales de "vigila el mempool". De pronto tu roadmap incluye generación de direcciones, seguimiento de confirmaciones en nueve redes, manejo de pagos incompletos, reorgs y gestión de llaves en un servidor de producción. Eso es un equipo de pagos, no un ticket de integración.

Lo que te cuesta elegir mal la integración

La decisión de pasarela parece reversible desde afuera. En la práctica, lo que conectes al ciclo de vida de tus pedidos se endurece rápido: los webhooks disparan el fulfillment, finanzas concilia contra eso, soporte arma flujos alrededor. Elegir mal se paga en tres monedas:

• Tiempo de ingeniería que no vuelve. Vigilar la cadena por tu cuenta empieza como un sprint y termina como una guardia permanente. Cada red nueva que pidan tus clientes duplica la superficie. Y la feature que querías — "que puedan pagar en USDC" — sigue sin salir.
• Riesgo de custodia que no pediste. Con una pasarela custodial, tu facturación vive en el libro contable de otro entre payout y payout. Una alerta de compliance, un cambio de políticas o un problema bancario del proveedor pueden congelar dinero que ya ganaste. Y si el proveedor cierra, tu acceso cierra con él — ya escribimos qué pasa cuando tu proveedor de pagos cripto cierra.
• Deuda de conciliación. Una API sin objetos de cobro serios — montos exactos, referencias, expiración, detección de sobrepago — convierte cada pago desajustado en un ticket de soporte y una fila de spreadsheet. Con volumen, "mandaron 49,97 en vez de 50,00" se vuelve un trabajo de medio tiempo.

El costo de no hacer nada también corre: mientras la integración espera, las tarjetas siguen cobrando ~3% por venta, los pagos internacionales siguen rebotando y los contracargos siguen cayendo sobre productos ya entregados.

Por qué las APIs de tarjetas y las pasarelas custodiales no lo resuelven

El problema es estructural, no cosmético. La API de un procesador de tarjetas — por limpia que sea — hereda la red de tarjetas que tiene debajo: 1–3 días entre autorización y liquidación, disputas que reabren una venta hasta ~120 días después, equipos de riesgo del adquirente que pueden retener o cerrar la cuenta, y spread de FX en todo lo internacional. Tu integración es tan final como el rail sobre el que viaja.

Las pasarelas cripto custodiales cambian la red de tarjetas por un libro contable que controla el proveedor — y eso reintroduce el mismo modo de falla en otra capa. El pago on-chain es final, pero tu derecho sobre él es un pagaré en su base de datos hasta que el payout se ejecute. Una finalidad que se detiene a un salto de tu wallet no es finalidad.

Lo que un desarrollador necesita de verdad es una pasarela donde la API gestione la mecánica del checkout (cobros, montos, confirmaciones, callbacks) y la liquidación vaya directo a una dirección que controla el comercio. Esa es la definición de un procesador de pagos cripto sin custodia — y es la arquitectura que Payzum expone por REST.

Qué le da a tu backend la API REST de Payzum

Payzum es un procesador de pagos no-custodial y solo-cripto con una superficie para desarrolladores pensada para sentirse como las APIs de pagos que tu equipo ya conoce — menos la custodia. Las piezas:

Cobros e invoices como objetos de primera clase

Tu servidor crea un cobro por un monto y una referencia exactos, autenticado con API key. Los invoices traen ventana de expiración y detección de sobrepago, así que los casos borde clásicos de cripto — pagó tarde, pagó de más, pagó apenas menos — son comportamiento de plataforma con estados definidos, no código a medida en tu servicio de pedidos.

Webhooks firmados para el ciclo del pedido

Cuando un pago confirma on-chain, Payzum llama a tu endpoint con un webhook firmado criptográficamente. Verificas la firma (un HMAC sobre el payload — el patrón estandarizado en el RFC 2104) y solo entonces marcas el pedido como pagado. Sin polling, sin confiar en callbacks anónimos, sin dar por pagado un pedido por una URL de redirección.

Un playground de integración antes de mover dinero real

El playground de integración te deja ensayar el ciclo completo — crear cobros, disparar confirmaciones, recibir y verificar webhooks, ejercitar expiración y sobrepago — antes de tu primera transacción real. Tu suite de tests puede cubrir el flujo de pagos como cubre todo lo demás.

Liquidación que se salta la pasarela por completo

Aquí está la diferencia arquitectónica: la API orquesta el pago, pero los fondos se mueven on-chain hacia tu wallet — Payzum nunca los retiene. Activa la auto-conversión y lo que sea que pague el cliente liquida como USDC o USDT: el monto en dólares que cobraste es el valor en dólares que conservas. Los pagos confirman en segundos en las redes rápidas: ~0,4s en Solana, ~2s en Base y Polygon.

El resto de la plataforma, con la misma cuenta

La API es una puerta a un stack completo: checkout hospedado (redirect, modal o inline) cuando prefieras no renderizar UI de pago, links de pago sin código, suscripciones recurrentes, donaciones y POS. Y si tu producto es una API, el mismo dashboard puede publicar un endpoint x402 para que los agentes de IA paguen por llamada en USDC sobre Base — sin trabajo de protocolo de tu lado.

Cómo funciona la integración, paso a paso

1. Crea tu cuenta, pasa el KYC y genera una API key. Regístrate en merchant.payzum.com, completa la verificación y emite tus keys desde el dashboard. Los secretos se guardan encriptados, la cuenta soporta 2FA y cada acción queda en un audit log completo.
2. Apunta la liquidación a una wallet que controles. Cualquier dirección cuyas llaves tengas tú — hardware wallet, MetaMask, Phantom, un multisig de tesorería. Activa opcionalmente la auto-conversión a USDC/USDT para protegerte de la volatilidad.
3. Conecta cobros y webhooks a tu flujo de pedidos. Crea el cobro server-side cuando arranca el checkout; verifica el webhook firmado para marcarlo pagado. Ensaya el ciclo entero en el playground de integración. Los esquemas y endpoints exactos están en la documentación de la API.
4. Sal a producción. Tus clientes pagan en USDC, USDT o cualquier activo soportado en Bitcoin, Ethereum, Solana, Polygon, Base, Arbitrum, Optimism, BNB Chain y Avalanche. El webhook dispara al confirmar y los fondos ya están en tu wallet.

Conceptualmente, el viaje completo es:

# 1) Tu backend crea un cobro (autenticado con API key)
POST /charges          → { amount, asset, reference, expires_in }
                       ← { charge_id, payment_details, status: "pending" }

# 2) El cliente paga desde cualquier wallet; la red confirma en segundos

# 3) Payzum te llama de vuelta — firmado
POST https://tuapp.com/webhooks/payzum
X-Signature: <HMAC del payload con tu secreto de webhook>
{ "charge_id": "...", "status": "confirmed", "reference": "pedido_1842" }

# 4) Verificas la firma → marcas el pedido pagado → despachas
#    Los fondos ya están en TU wallet — no existe el paso "payout".

El paso 4 es el que se siente raro si vienes de procesadores tradicionales: en ningún punto del ciclo hay un estado "esperando payout". La liquidación es el pago.

Qué construyen los equipos sobre una API de pagos cripto

Cuatro montajes que vemos en equipos de ingeniería, todos sobre la misma superficie REST:

• Marketplace con carrito propio: un marketplace latinoamericano crea un cobro por pedido, asocia webhooks a IDs de orden y despacha en cuanto el pago confirma en Polygon. Los compradores del exterior cuyas tarjetas rebotaban ahora pagan en USDC, y finanzas concilia contra referencias de cobro en lugar de extractos bancarios.
• SaaS con facturación in-house: un SaaS B2B agrega "pagar en stablecoins" junto a las tarjetas en su propia UI de billing. Los invoices llevan ventana de expiración, las renovaciones viajan por cobro recurrente en cripto y los ingresos dejan de morir por disputas — on-chain no existe la ventana de contracargo.
• Tienda headless: una marca DTC con stack headless incrusta el checkout hospedado inline para el paso de pago, pero gobierna todo lo demás — creación del pedido, estados, recibos — por API y webhooks firmados. Sin UI de pago que construir, control total del flujo.
• Empresa de APIs monetizando tráfico de agentes: un proveedor de datos que ya usa la API REST para clientes humanos configura su endpoint, su key y un precio en el dashboard, y Payzum publica una URL x402 delante. Los agentes de IA pagan USDC en Base por llamada — liquidado, como todo lo demás, directo en la wallet de la empresa.

API de Payzum vs APIs de pasarelas custodiales — qué cambia

Objeciones frecuentes de desarrolladores — respondidas

"No quiero operar infraestructura blockchain."

No la operas. Payzum maneja direcciones, detección de pagos y seguimiento de confirmaciones en las nueve redes soportadas. Tu lado de la integración es HTTPS: crear cobros con una API key y verificar firmas de webhook con tu secreto. Cero nodos, cero proveedores RPC y cero llaves privadas en tus servidores — la liquidación va a una wallet que gestionas donde ya la gestionas.

"Los pagos son finales — ¿y los reembolsos y disputas?"

La finalidad elimina las reversas involuntarias: ningún banco puede deshacer una venta liquidada cuatro meses después, y por eso los ingresos on-chain concilian tan limpio. El servicio al cliente sigue siendo tuyo: cuando un reembolso corresponde, devuelves los fondos desde tu wallet bajo tu política. Conservas la decisión; pierdes la cuota de disputas, las comisiones de arbitraje y el fraude de "no me llegó" sobre productos entregados.

"Ya tenemos procesador de tarjetas — ¿esto es una migración?"

No. El patrón estándar es aditivo: cripto corre junto a las tarjetas como un método de pago más, gobernado por el mismo ciclo de pedidos. Tu flujo de tarjetas no cambia. Los primeros en usarlo son justo los clientes que las tarjetas te hacen perder: compradores internacionales, usuarios nativos de stablecoins y cualquiera cuyo rail local no funciona.

"¿Cuánto cuesta por transacción?"

La liquidación viaja sobre comisiones de red on-chain — centavos en Base, Polygon y Solana — en lugar de un porcentaje de la venta. // confirmar pricing actual — agenda una llamada para el pricing vigente según tu volumen.