Solicitudes de Transacción
Transacciones generadas por el servidor para flujos de pago de Solana Pay.
Receta
// La API del comerciante devuelve application/vnd.solana.transaction+json o un cuerpo que cumple con las especificaciones
import { createSolanaRpc } from "@solana/kit";Cuándo usar esto:
- El checkout necesita swap, mint o un programa personalizado, no una simple transferencia de SOL.
- El código QR del TPV abre la billetera con una vista previa completa de la transacción.
- Emparejamiento con claves públicas de referencia para la conciliación.
Ejemplo Funcional
import { NextRequest, NextResponse } from "next/server";
import {
createSolanaRpc,
createTransactionMessage,
setTransactionMessageFeePayerSigner,
setTransactionMessageLifetimeUsingBlockhash,
appendTransactionMessageInstruction,
address,
} from "@solana/kit";
export async function GET(req: NextRequest) {
const account = req.nextUrl.searchParams.get("account");
if (!account) return NextResponse.json({ error: "falta la cuenta" }, { status: 400 });
const rpc = createSolanaRpc(process.env.RPC_URL!);
const { value: bh } = await rpc.getLatestBlockhash().send();
// Construir transacción con el cliente como pagador de tarifas (parámetro account)
let msg = createTransactionMessage({ version: 0 });
// adjuntar instrucciones del comerciante que referencian la cuenta como firmante/pagador
// serializar a transacción de cable en base64 para la billetera
return NextResponse.json({
transaction: "BASE64_WIRE_TX",
message: "Completa tu compra",
});
}Lo que esto demuestra:
- La clave pública del cliente llega como parámetro de consulta desde la billetera.
- El servidor construye el mensaje; el cliente firma como pagador de tarifas.
- Devuelve JSON con formato de especificación para el consumo de la billetera.
Análisis Profundo
Cómo Funciona
- La billetera escanea el código QR o el enlace → obtiene la API del comerciante → muestra la transacción → el usuario firma.
- Las cuentas de referencia vinculan la transacción en cadena con el ID del pedido.
- Se requiere HTTPS para la confianza en producción.
Errores Comunes
- Confiar en el indicador de pago del cliente sin verificación RPC - fraude. Solución: trabajo de confirmación del servidor.
- Parámetro de cuenta no validado - construir transacciones para claves elegidas por el atacante está bien, pero registrar el abuso.
- Blockhash obsoleto en respuesta en caché - falla la confirmación. Solución: generar por solicitud.
- Falta de CORS - la billetera web no puede obtener la API. Solución: cabeceras CORS de Acciones según la especificación.
- Transacción sobredimensionada - la billetera la rechaza. Solución: ALTs e instrucciones concisas.
Alternativas
| Alternativa | Usar Cuando | No Usar Cuando |
|---|---|---|
| URL de transferencia simple | Pago simple de SOL | Necesita swap/mint |
| Checkout de custodia | Rampas de acceso a fiat | Comerciante de autocustodia |
Preguntas Frecuentes
¿App Router?
Proveedores en el layout cliente layout.tsx; las páginas mezclan componentes de servidor y cliente.
¿Secretos?
Solo variables de entorno del servidor para keypairs; NEXT_PUBLIC_ para URLs RPC.
¿kit 7.0.0?
Todos los ejemplos usan @solana/kit, no web3.js v1.
¿Billetera?
Firma solo en componentes cliente.
¿Caché?
Revalidar lecturas en cadena con cuidado - la cadena es la fuente de verdad.
¿Acciones?
Endpoints HTTPS que devuelven JSON de Acciones de Solana.
¿Móvil?
Aplicación React Native separada con MWA.
¿Pruebas?
Surfpool para integración; simular RPC en pruebas unitarias.
¿Mainnet?
Archivos de entorno e IDs de programa separados.
¿Errores?
Decodificar registros de simulación para mensajes dirigidos al usuario.
Relacionado
- Fundamentos de Solana Pay - Introducción a QR
- Creación de una Acción - Superposición de Acciones
- Rutas API para Transacciones - Next.js
Versiones de Stack: Esta página fue escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, anchor-lang 0.32.1, Rust 1.91.1, @solana/kit 7.0.0, Surfpool 0.12.0, y LiteSVM 0.6.x.