Solana Pay, Actions e Blinks
Solana Pay, Actions e Blinks são a stack de interação embutível da Solana: formas de solicitar valor ou assinaturas fora de um shell dApp customizado completo.
//
Busque em todas as páginas da documentação
Solana Pay, Actions e Blinks são a stack de interação embutível da Solana: formas de solicitar valor ou assinaturas fora de um shell dApp customizado completo.
Compartilham uma ideia. Um client (wallet, provedor Blink ou scanner QR) descobre uma intenção, opcionalmente busca uma transação construída no servidor e pede ao usuário para assinar. Você possui o endpoint HTTPS e instruções; a wallet possui chaves e a tela de aprovação.
Esta página é o guarda-chuva da seção. Páginas irmãs cobrem URLs de pagamento, transaction requests, contrato HTTP Actions, Blinks, implementação e verificação.
Comece com Solana Pay como camada de pagamento.
Um transfer request codifica destinatário, valor (e mint SPL opcional), label, message e chaves públicas de referência opcionais em URL que wallets entendem. Comerciantes renderizam como QR para ponto de venda ou compartilham para checkout remoto. A wallet preenche transferência; o usuário assina; a chain liquida.
Referências dirigem bookkeeping. Uma pubkey de referência única por pedido permite que seu servidor observe RPC ou websockets por transação correspondente e marque fatura como paga sem confiar apenas em callback do browser. Valor e mint ainda precisam de verificações no servidor; referência correspondente é correlação, não prova completa sozinha.
Transaction requests elevam o mesmo padrão "wallet busca intenção de HTTPS" além de transferências simples. O endpoint do comerciante recebe conta do cliente, constrói transação versionada com essa conta como fee payer ou signer obrigatório e retorna transação serializada que a wallet pode visualizar e assinar. Checkout pode fazer swap, mint ou chamar programa customizado em uma aprovação.
Solana Actions generaliza endpoints que produzem transações além de pay clássico de comerciante. A especificação Actions define como clients descobrem metadata legível (title, icon, description, label e campos relacionados) e como obtêm transação codificada em base64 para account conectada. Wallets, portais Blink e unfurlers sociais falam o mesmo contrato.
Blinks (blockchain links) são a camada de distribuição. Um Blink é URL de Action apresentada por client ou proxy compatível com Blink para unfurl em card rico: ícone, copy e botão que executa fluxo POST de Action. A Action permanece sua API HTTPS; o Blink é como usuários encontram e compartilham no X, Discord, sites parceiros e superfícies Blink.
Este site constrói código client e servidor com @solana/kit 7.0.0, faz deploy de programas sob Agave 4.1.1 / Solana CLI 3.0.10 e frequentemente compõe instruções de programas Anchor 0.32.1 em Rust 1.91.1. Pay e Actions são principalmente TypeScript e HTTP; os programas que você invoca ainda obedecem regras de conta e CU do Sealevel.
encodeURL do @solana/pay ou campos construídos manualmente conforme spec Pay).Use transfer requests quando a ação é "enviar N do ativo X para destinatário Y" sem composição multi-instrução no servidor.
https://merchant.example/pay?... (ou formato transaction-request que sua wallet suporta).Transaction requests e Actions sobrepõem-se muito. Muitos produtos implementam Actions (ou handlers compatíveis com Action) e tratam transaction requests Solana Pay como ancestral do mesmo padrão com sabor de pagamento.
| Método | Papel |
|---|---|
OPTIONS | Preflight CORS para clients browser e extension |
GET | Metadata read-only para cards e unfurlers |
POST | Aceita { account } (e campos body opcionais), retorna { transaction } base64 |
GET não deve mutar estado. É apresentação cacheável: ícone HTTPS, title, description, label de botão, inputs opcionais. POST é dinâmico por usuário: insira pubkey dele como signer/fee payer, defina blockhash fresco, anexe apenas contas e instruções necessárias para aquele CTA.
Clients mostram sua metadata, depois POST o endereço da wallet conectada. Seu servidor retorna transação que a wallet assina. Callbacks opcionais reportam conclusão; nunca os trate como prova única sem confirmação RPC.
Um client Blink pega URL de Action (frequentemente via query de provedor como ?action=https://...) e:
Seu trabalho permanece o endpoint Action: CORS, TLS, metadata precisa e transações least-privilege. Provedores Blink e wallets adicionam allowlists, avisos e badges; isso complementa construção segura, não substitui.
Actions de produção geralmente vivem como route handlers (por exemplo Next.js App Router em app/api/actions/...):
account, constrói instruções (builders Kit ou helpers Codama/IDL para programas Anchor), define fee payer e blockhash, serializa base64.Separe program IDs e URLs RPC para devnet e mainnet-beta. Action mainnet apontando para program ID devnet é bug comum de lançamento.
SetAuthority inesperado, aprovações ilimitadas ou transferências não relacionadas.Verificação no lado Blink também cobre registries de client, verificações de domínio e integridade de unfurl (ícone ainda no seu host). Trate caches de unfurl como propensos a obsolescência; versione URLs de assets estáticos quando branding mudar.
| Necessidade | Prefira | Evite quando |
|---|---|---|
| Pagamento SOL/SPL presencial | Solana Pay transfer + QR | Precisa composição multi-ix |
| Checkout com swap/mint/ix customizada | Transaction request ou Action | URL de transferência simples basta |
| CTA social compartilhável | Action + Blink | Apenas PDV offline |
| UX de produto multi-tela completa | dApp wallet-adapter | Só precisa CTA de um toque |
| Movimentação de dinheiro alto risco | Programa escrow + liquidação verificada | Confiar apenas em eventos "paid" do client |
Muitos times rodam ambos: Solana Pay ou Actions para aquisição e PDV, e dApp completo para power users. A habilidade compartilhada é construir transações seguras para pubkey de cliente.
Use @solana/kit 7.0.0 para RPC, endereços, construção de mensagem e codificação wire. Prefira transações versionadas e simulação. Para programas Anchor 0.32.1, gere builders tipados (Codama/IDL) para que account metas permaneçam corretos conforme programas evoluem.
Uma Action apenas entrega transação que o usuário assina; não relaxa verificações Sealevel, PDAs, regras de token ou limites de CU nos programas que você chama.
Operacionalmente: cache CDN de metadata GET estável, nunca cache txs POST entre usuários; rotacione blockhashes a cada POST; registre latência e falhas sem secrets em query strings; se Action ruim for ao ar, tire rota offline e rotacione assets quando clones de phishing aparecerem.
/vote, /mint, /pay) em vez de builders abertos.Permitem que usuários completem intenções on-chain (pagar, votar, mintar, fazer swap) a partir de links, QR codes e superfícies sociais sem forçar toda interação por dApp multi-página customizado.
Quando a intenção é pagamento SOL ou SPL simples para destinatário e valor conhecidos e você não precisa de lógica multi-instrução ou CTAs sociais com unfurl. URLs de transferência são a menor superfície.
Chave pública incluída no pagamento para seu backend encontrar transação on-chain correspondente e ligá-la a id de pedido. Gere referência única por sessão de checkout e verifique valor no servidor.
Transfer requests descrevem pagamento que a wallet pode construir localmente. Transaction requests atingem sua API HTTPS para o servidor retornar transação completa (swap, mint, programa customizado, etc.) para o cliente assinar.
No mínimo: CORS/OPTIONS conforme exigido por clients, metadata GET para exibição humana e POST que aceita conta do usuário e retorna transação base64. Siga campos da especificação Actions atual que suas wallets alvo suportam.
Geralmente não. A Action é a API. Blink é como essa Action é linkada, unfurled e apresentada dentro de apps e provedores compatíveis com Blink.
Clients carregam ícones para cards e unfurls. Hotlinking ou assets HTTP quebram renderização, enfraquecem sinais de confiança e criam risco de supply chain se terceiro troca imagem.
Sim. Kit é a stack TypeScript que este site fixa para RPC, endereços e construção de mensagem de transação em handlers POST.
Não. Actions são HTTP mais qualquer transação Solana válida. Anchor 0.32.1 ajuda quando seu CTA chama programa Anchor e você quer builders orientados por IDL; programas nativos funcionam igual no nível wire.
Confirme via RPC (e preferencialmente websockets ou indexer) transação que corresponda a regras de referência, valor, mint e destinatário no seu nível de commitment. Não confie em callbacks apenas do client.
Transações com privilégios excessivos, pular simulação, patrocínio de taxa sem cap, rate limits ausentes e program IDs de cluster errado em produção.
Clients podem avisar, allowlist ou mostrar badges de verificação. Assuma que usuários ignoram avisos; mantenha transações mínimas e domínios consistentes com sua marca.
Sim para branding estável, com TTLs curtos se títulos mudam frequentemente. Nunca cache respostas POST de transação entre usuários ou tempo.
Comece com Noções Básicas de Solana Pay e Transaction Requests, depois Actions (a spec) e Blinks. Implemente com Construindo uma Action e endureça com Segurança e Verificação.
Versões da stack: Esta página foi escrita para Agave 4.1.1, Solana CLI 3.0.10, Anchor 0.32.1, Rust 1.91.1 e @solana/kit 7.0.0.
Revisado por Chris St. John·Última atualização: 15 de jul. de 2026