Diseñado para compradores que no son humanos.
Cada enlace de pago de CryptoPayIn y cada tienda funciona también como un pago legible por máquinas. Un agente de IA descubre lo que usted vende, crea una factura y paga on-chain en tres llamadas HTTP: sin navegador, sin clave de API, sin intervención humana. Entrega incluida, en JSON.
Tres llamadas. Eso es toda la integración.
Tome cualquier enlace, por ejemplo https://cryptopaylink.co/pay/PL-XXXXXXX.
Añada .json y el flujo automatizado se pone en marcha. Todo lo que sigue ya está activo hoy, en cada enlace.
Qué se vende, el precio, los activos aceptados y los campos exactos que espera la llamada de facturación: autodescriptivo, de modo que un agente no necesita ningún conocimiento previo del vendedor.
{
"protocol": "cpi-agent-checkout/1",
"link": {
"id": "PL-XXXXXXX", "state": "ok",
"title": "Pro license — 1 seat",
"pricing": { "currency": "USD", "type": "fixed", "amount": "12.00" },
"delivery": { "type": "keys", "description": "A unique key reserved for you…" }
},
"payment_assets": [ { "asset": "BTC", "network": "mainnet", "min_usd": "5.00" }, … ],
"checkout": { "create_invoice": { "method": "POST", "url": "…/invoice" }, … }
}Un solo cuerpo JSON: el activo, más lo que exija el enlace (importe para precios abiertos, variante,
campos del comprador, envío para productos físicos). Incluya una cabecera Idempotency-Key y los reintentos nunca podrán generar una factura duplicada.
curl -X POST https://cryptopaylink.co/pay/PL-XXXXXXX/invoice \
-H "Content-Type: application/json" \
-H "Idempotency-Key: agent-run-42" \
-d '{ "asset": "BTC", "fields": { "Discord username": "buyer#0001" } }'
{ "ok": true, "invoice": {
"payment": "P-XXXXXXXXXX",
"pay": { "asset": "BTC", "network": "mainnet",
"address": "bc1q…", "amount": "0.0001867",
"uri": "bitcoin:bc1q…?amount=0.0001867" },
"expires_at": "2026-07-20T11:00:25Z",
"receipt": "…/receipt?p=P-XXXXXXXXXX" } }El importe es exacto y el tipo de cambio queda fijado: el agente envía exactamente
pay.amount en pay.network desde cualquier cartera que controle. Sin SDK, sin esquema de firma, sin facilitador.
Consúltelo cada pocos segundos. Las confirmaciones avanzan y, en el instante en que el pago se completa, la respuesta contiene la entrega: contenido, enlace o una clave de licencia reservada exactamente para este pago.
Las tiendas hablan el mismo protocolo. GET /s/SH-x.json muestra el catálogo completo de una
tienda (productos, variantes, existencias en tiempo real); un único POST /s/SH-x/order convierte un carrito en una factura
pagable: el recibo se encuentra en /s/SH-x/o/ORD-…/receipt.
{ "ok": true, "receipt": {
"payment": "P-XXXXXXXXXX", "status": "completed",
"paid_at": "2026-07-20T10:30:58Z",
"delivery": { "type": "keys", "key": "LICENSE-XXXX-YYYY",
"note": "Delivered once, tied to this payment — store it now." },
"next": "done" } }Ingeniería aburrida, a propósito
Las facturas de los agentes pasan por la misma validación, el mismo bloqueo de tipo de cambio y la misma derivación de direcciones que la página alojada: una única ruta de código, sin una implementación paralela que pueda desviarse o explotarse.
Los endpoints para agentes consumen los mismos cupos de límite de solicitudes y los mismos topes de facturas pendientes que la página. Activar los agentes no añade ninguna capacidad extra para el agotamiento de direcciones o el spam.
Sin cookies, sin sesiones, sin superficie CSRF en el dominio de pago. El identificador de pago es la única capacidad, igual que en la URL de recibo humana.
La cabecera Idempotency-Key hace que la creación de facturas sea segura frente a reintentos; la misma clave con un cuerpo distinto se rechaza con un 409.
El pago de agentes se gestiona por cuenta y está activado de forma predeterminada. Desactivarlo implica un 403 en los endpoints para máquinas, mientras que todas las páginas para humanos siguen funcionando.
Las páginas para humanos envían Link: …/pay/PL-x.json; rel="alternate", y este contrato se resume en llms.txt para los motores de respuesta.
Todo lo que un enlace de pago puede vender
Contenido de texto, URLs privadas, claves de licencia de un solo uso: se entregan en el JSON del recibo, reservadas por pago, sin condiciones de carrera bajo los límites de existencias.
Precios fijos en cualquiera de las 30 divisas fiduciarias, o importes abiertos (propinas, facturas, recargas) con un mínimo/máximo definido por el vendedor: el agente indica "amount".
Variantes de producto con existencias por variante, además de campos obligatorios personalizados (nombres de usuario, notas del pedido) declarados en el documento de descubrimiento.
La llamada de facturación acepta una dirección de envío estructurada, validada según el país de destino: los agentes pueden pedir artículos que llegan en cajas.
GET /s/SH-x.json expone el catálogo completo de una tienda con existencias en tiempo real; un único POST …/order valida el carrito, reserva las existencias y devuelve la factura.
Vender a agentes es el lado del comprador. Si está construyendo el lado del vendedor —crear enlaces, consultar saldos, retirar fondos—, eso corresponde a la API REST para comerciantes, y es igual de programable.
Preguntas sobre agentes, respondidas con claridad
¿Necesita un agente una clave de API o una cuenta?
No. El descubrimiento, la creación de la factura y el recibo son endpoints públicos limitados a un único enlace de pago, exactamente igual que la página de pago para humanos. El identificador de pago devuelto en la creación es la única credencial que el agente necesita para consultar su propio recibo. Las claves de API para comerciantes existen para los vendedores, no para los compradores.
¿Cómo paga realmente el agente?
La respuesta de la factura contiene una dirección de depósito, un importe exacto y una URI al estilo BIP-21. Cualquier cartera que el agente controle —una cartera BTC, un firmante EVM, un par de claves de Solana, una cartera de Monero— envía ese importe en la red indicada. No hay ningún esquema de firma propietario que integrar.
¿Es esto x402?
Es independiente del protocolo. Cualquier stack capaz de hacer llamadas HTTPS y difundir una transacción cripto puede pagar: sin facilitador, sin un SDK de cartera especial. Si su framework habla x402 o AP2, envuelva la llamada de facturación en su herramienta de pago; el contrato JSON encaja perfectamente en un flujo al estilo 402, y la negociación nativa de x402 está en la hoja de ruta.
¿Qué enlaces y tiendas admiten el pago de agentes?
Todos los enlaces de pago activos y todas las tiendas activas, de forma predeterminada: precios fijos, importes abiertos, variantes de producto, campos del comprador, productos físicos con envío y catálogos completos de tienda con existencias en tiempo real. Los vendedores pueden desactivar el pago de agentes por cuenta en Configuración; en ese caso, los endpoints responden 403 mientras las páginas para humanos siguen funcionando.
¿Qué recibe el agente después de pagar?
El endpoint de recibo devuelve la entrega en JSON en el instante en que el pago se completa: el contenido, el enlace privado o una clave de licencia reservada para ese pago. Los pedidos físicos confirman que el vendedor recibió la dirección de envío.
¿Puede un agente malicioso abusar de los endpoints?
Las llamadas de los agentes comparten exactamente los mismos cupos de límite de solicitudes, topes de facturación y reglas de idempotencia que la página de pago alojada: no añaden ninguna capacidad de ataque adicional. No hay cookies ni sesiones en el dominio de pago, por lo que no existe ningún estado que una llamada entre sitios pueda aprovechar.
Su próximo cliente podría ser un script.
Su cuenta está a un clic de distancia: sin KYC, sin esperas. Una comisión fija del 1 % por transacción. Sin suscripciones ni costes de configuración.