Machine Payments Protocol en Solana

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 una session medida.
  • 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:

MensajeRepresentación HTTP
Desafío de pago402 Payment Required con WWW-Authenticate: Payment ...
Credencial de pagoSolicitud reintentada con Authorization: Payment ...
Recibo correctoRespuesta del recurso con Payment-Receipt: ...
Detalles de pago no válidosCuerpo de Problem Details que usa application/problem+json
MPP Charge Flow

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 express
pnpm 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.ts
curl -i http://127.0.0.1:4567/report
pay --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.

MPP Session Lifecycle

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?

Tabla de Contenidos

Editar Página