Gateway de pagos para aceptar USDT y USDC
Aceptar USDT y USDC para cobros cross-border implica más que generar una dirección de depósito. Hay que emitir el cobro, confirmar que el pago entrante no viene de fondos marcados, y liquidar al comercio sin acreditar dos veces por un webhook repetido. Esta arquitectura de referencia describe un PSP que cubre checkout, control AML sobre lo que entra y settlement, todo con una key y un saldo compartido en credits.
El desafío
Un gateway de stablecoins tiene que resolver tres problemas que en el mercado hispanohablante son cotidianos: cobrar remesas y pagos cross-border en USDT/USDC, cumplir con AML sobre fondos que llegan de wallets desconocidas, y entregar el dinero al comercio. El riesgo operativo está en los detalles: pagos de menos y de más, confirmaciones que tardan, y entregas de eventos duplicadas que —mal manejadas— acreditan el mismo cobro dos veces. Si cada capa es de un proveedor distinto, coordinar la aprobación con el settlement se vuelve frágil.
- Invoices / checkoutC2
- Transaction screening / KYTC3
- Sanctions check + feedC2
- Mass payout / settlementC2
Checkout alojado con seguimiento de confirmaciones
El cobro se emite con invoices/checkout alojado: el comercio genera la orden y el pagador envía USDT o USDC. La plataforma sigue el estado del pago —confirmaciones en cadena, pagos de menos y de más— para que el comercio vea con precisión si la orden quedó completa, parcial o excedida, sin montar un watcher propio por cadena.
KYT y sanctions antes de aprobar el cobro
Sobre los fondos entrantes se ejecuta KYT y screening de sanctions: la fuente del pago se evalúa antes de dar la orden por aprobada. Solo los pagos que pasan el control avanzan a settlement; los que caen en review o block quedan retenidos con su decisión registrada, lo que da al comercio una traza defendible ante auditoría.
Settlement idempotente al comercio
La liquidación al comercio corre contra el mismo saldo en credits. Los eventos que emite el gateway son firmados e idempotentes: una entrega duplicada del webhook no acredita el cobro dos veces, porque cada evento lleva su identificador y el consumidor puede deduplicar con seguridad. Cobro, control AML y settlement comparten la misma key.
Lo que entrega la arquitectura
- Cobros en USDT/USDC con checkout alojado que distingue pago completo, parcial y excedido sin infraestructura propia por cadena.
- Solo los pagos que pasan KYT y sanctions llegan a settlement, con la decisión registrada para auditoría.
- Eventos firmados e idempotentes: un webhook duplicado nunca acredita el mismo cobro dos veces.
Preguntas frecuentes
¿Qué pasa si el cliente paga de menos o de más en la invoice?
El estado del cobro refleja la diferencia: el checkout marca la orden como parcial o excedida según lo recibido en cadena, para que el comercio decida si completa, reembolsa o acredita el saldo a favor.
¿Cómo evito acreditar dos veces si me llega el webhook repetido?
Cada evento es firmado y trae un identificador único. Al ser idempotentes, tu consumidor deduplica por ese identificador y una segunda entrega del mismo evento no genera un segundo abono.
Recarga, obtén tu clave y publica.
Autoservicio. Paga en cripto o con tarjeta. Medido por créditos: las primitivas pesadas cuestan más, las simples son baratas.
Obtener clave API