El Machine Payments Protocol (MPP) aplica la semántica de autenticación de HTTP a los pagos. Un servidor plantea un desafío ante una solicitud sin pagar, un cliente devuelve una credencial de pago y el servidor devuelve un recibo después de aceptar el pago.
MPP separa tres aspectos:
- Una intención describe la interacción comercial, como un
chargeúnico o unasessionmedida. - Un método de pago describe cómo se mueve el valor. El método de Solana admite SOL nativo y tokens SPL para los cobros.
- Un transporte HTTP transporta los desafíos, las credenciales, los recibos y los errores.
MPP se publica como un conjunto de Internet-Drafts. Considera las especificaciones actuales como la fuente de referencia y ten en cuenta que los detalles pueden cambiar mientras los borradores estén en desarrollo.
Intercambio HTTP
MPP usa los campos estándar de autenticación HTTP en lugar de encabezados de pago específicos del protocolo:
| Mensaje | Representación HTTP |
|---|---|
| Desafío de pago | 402 Payment Required con WWW-Authenticate: Payment ... |
| Credencial de pago | Solicitud reintentada con Authorization: Payment ... |
| Recibo correcto | Respuesta del recurso con Payment-Receipt: ... |
| Detalles de pago no válidos | Cuerpo de Problem Details que usa application/problem+json |
Un desafío incluye un ID generado por el servidor, el realm, el método, la intención, la solicitud de pago codificada y la caducidad. La credencial repite el desafío y añade la prueba de pago específica del método. El servidor debe verificar ambos elementos; una transferencia válida que pertenezca a un desafío distinto no debe desbloquear el recurso.
Cobros únicos en Solana
La intención charge de Solana admite dos tipos de credenciales:
- El modo pull usa una transacción firmada. El cliente firma la transferencia y envía la transacción al servidor. El servidor la verifica, añade opcionalmente una firma del pagador de comisiones, la transmite, la confirma y devuelve la firma de la transacción en su recibo.
- El modo push usa una firma de transacción. El cliente transmite primero y luego envía la firma confirmada al servidor. El servidor obtiene y verifica la transacción antes de devolver el recurso.
El modo pull permite que el servidor patrocine las comisiones de transacción y aplique lógica de reintento en el servidor. El modo push es útil cuando una wallet requiere que el cliente envíe su propia transacción, pero no puede usar el patrocinio de comisiones del servidor.
Para consultar los campos normativos y las reglas de verificación, consulta la especificación de cobros de Solana.
Añadir un cobro MPP a una API de Express
Solana Pay Kit ofrece una integración actual en TypeScript para MPP y x402. Instálalo con Express:
pnpm add @solana/pay-kit @solana/kit@^6.9.0 expresspnpm add --save-dev @types/express tsx
Este ejemplo mínimo usa el sandbox alojado de Surfpool y el destinatario de demostración público del paquete. Es solo para desarrollo local:
import express from "express";import { createPayKit, usd } from "@solana/pay-kit";const pay = await createPayKit({accept: ["mpp"],rpcUrl: "https://402.surfnet.dev:8899"});const app = express();app.get("/report", pay.express(usd("0.01")), (_req, res) => {res.json({ report: "Paid report" });});app.listen(4567, () => {console.log("Paid API listening on http://127.0.0.1:4567");});
Ejecútalo y compara una solicitud sin pagar con una solicitud compatible con pagos:
pnpm tsx server.tscurl -i http://127.0.0.1:4567/reportpay --sandbox curl http://127.0.0.1:4567/report
El controlador de la ruta solo se ejecuta después de que el middleware acepte el pago.
Sustituye todos los valores predeterminados del sandbox en producción
Configura una red explícita, un destinatario comercial, un RPC dedicado, un secreto estable de vinculación de desafíos, un firmante de producción y un almacén duradero contra repeticiones. No dirijas nunca pagos reales a un firmante de demostración de un paquete.
Sesiones medidas
Usa una session de Solana MPP cuando un cliente vaya a realizar muchos pagos pequeños y relacionados.
Una sesión abre un canal de pago onchain con un depósito máximo y luego usa
vouchers firmados acumulativos a medida que crece el uso. El servidor puede verificar los vouchers
offchain y liquidar más tarde el importe más alto aceptado.
Esto resulta útil para inferencia medida por tokens, descargas medidas por bytes, datos en tiempo real y llamadas repetidas a herramientas. No equivale a enviar un pago onchain independiente por cada evento.
Llama a una sesión pago de sesión, canal de pago o autorización repetida con límite. Habla de pago en streaming solo cuando el servicio y el contrato de pago midan realmente un flujo de uso.
Verificación en producción
Para cada cobro de Solana, el servidor debe verificar como mínimo lo siguiente:
- El desafío es auténtico, no ha caducado, está vinculado a esta solicitud y está destinado a este realm.
- La transacción usa la red, el activo o mint, el destinatario, el importe y el programa de tokens esperados.
- Las instrucciones del pagador de comisiones o de la associated token account están permitidas de forma explícita y no pueden vaciar el firmante del servidor.
- La transacción se completó con éxito en el nivel de commitment requerido.
- La firma de la transacción no se ha consumido ya.
- La comprobación de repetición y la operación de consumo son atómicas en todas las instancias del servidor.
En el caso de las sesiones, conserva también el estado del canal, el importe acumulado aceptado y la marca de liquidación en un almacén compartido. Documenta cómo recuperan los clientes los fondos no utilizados si el servidor deja de estar disponible.
Recursos relacionados
Is this page helpful?