Communitygithub.com

UNIPaaS/agent-skills

Crie integrações Unipaas com seu agente de IA.

O que é agent-skills?

Esta skill capacita agentes de IA (como Claude Code, Cursor ou Codex) a construir integrações completas com a plataforma Unipaas, que oferece pagamentos embarcados para plataformas digitais e marketplaces. O agente pode gerenciar todo o ciclo de vida de transações: onboard de vendedores (sub-mercantis), aceitar pagamentos, gerenciar contas e saldos, e realizar pagamentos — tudo em conformidade com PSD2 e PCI. A skill suporta três níveis de integração (sem código, baixo esforço e médio esforço) e quatro produtos principais (onboarding, aceitação de pagamentos, gestão de contas e pagamentos). Inclui suporte a modos de autenticação servidor a servidor e fluxo de autorização em duas etapas, além de SDKs de checkout no lado do cliente (secure-fields e web-embeds). O agente pode consultar documentações detalhadas em referências como `auth.md`, `accept-payments.md`, `web-sdk.md` e `security.md` para implementar a integração completa.

Funciona com~Claude Code~Codex CLI~Cursor
npx skills add UNIPaaS/agent-skills

Perguntar na sua IA favorita

Abre um novo chat com esta habilidade de agente já pré-carregada.

Documentação

Unipaas

Fundamentos

A Unipaas fornece pagamentos embarcados de ponta a ponta para plataformas digitais e marketplaces (SaaS, economia gig, marketplaces B2B/B2C). Você cadastra vendedores (sub-mercantis), aceita pagamentos, gerencia contas (saldos) e faz pagamentos — controlando fluxos de dinheiro e mantendo conformidade com PSD2/PCI.

Obtenha uma chave de sandbox. Crie uma conta de teste gratuita em https://portal.unipaas.com/signup. A conta de teste é ilimitada e está sempre disponível. Encontre sua Chave Privada no portal, na seção de desenvolvedor/chaves. As credenciais de sandbox e produção (Live) são completamente separadas e não compartilham dados.

URLs base.

  • Sandbox: https://sandbox.unipaas.com/platform
  • Produção (Live): https://api.unipaas.com/platform

Dois modos de autenticação (detalhes em references/auth.md).

  1. Servidor a servidor: envie sua Chave Privada como Authorization: Bearer {{PRIVATE_KEY}} diretamente nas chamadas de API (criação de checkout, pagamentos, contas, pagamentos, onboarding). A chave privada deve permanecer no servidor.
  2. Fluxo de /authorize em duas etapas (para embeds de plataforma no lado do cliente): seu servidor faz POST da chave privada para /authorize com scopes e (geralmente) um vendorId, e recebe um accessToken temporário. O cliente usa esse token de acesso — nunca a chave privada.

Idempotência. Para evitar execução duplicada em repetições, adicione um cabeçalho requestId: <id> a requisições POST. A mesma requestId aplicada várias vezes produz um único resultado. IDs de requisição são válidos por 24 horas.

Mapa de decisão

Quatro produtos, três níveis de integração. Escolha o nível que corresponde à sua capacidade de desenvolvimento e postura de PCI.

ProdutoSem códigoBaixo esforçoMédio esforço
OnboardingLink de onboarding hospedadoUI embarcada (unipaas.components)API de onboarding
Aceitar pagamentosLink de pagamento (portal)Página de checkout / SDK WebAPI de pagamento (servidor a servidor)
Gestão de contasVisualização no portalComponente de conta/saldoAPI de contas
Pagamento de fundosPagamento manual/agendado via portalFormulário de pagamento / Componente de contaAPI de pagamentos

Orientação:

  • Quer zero código? Use Link de pagamento, link de onboarding hospedado, pagamentos via portal.
  • Quer sua própria UI com baixo esforço + PCI reduzido? Use a Página de checkout (redirecionamento), campos seguros do SDK Web, ou web-embeds do comprador; use embeds de plataforma para onboarding/saldo/portal.
  • Quer controle total / white-label / aplicativo nativo? Use as APIs. API de pagamento (dados brutos de cartão) requer PCI SAQ D.

Nota: uma transação enviada sem um vendorId é registrada contra a conta da plataforma.

Caminhos de checkout no lado do cliente

Veja references/web-sdk.md para etapas completas. Dois caminhos de pagamento do comprador, ambos autenticados com o sessionToken retornado por um POST /pay-ins/checkout do lado do servidor — não o token de acesso /authorize.

  1. SDK de campos seguros — carregue https://cdn.unipaas.com/unipaas.sdk.js (expõe o global Unipaas). Crie seu próprio formulário de cartão, então new Unipaas().initTokenize(sessionToken, fields, options). Campos seguros são um recurso deste pacote, não um pacote separado.
  2. Web-embeds do comprador — carregue https://cdn.unipaas.com/embedded-ui.js, então unipaas.buyerComponents(sessionToken, config) e .create("checkout"|"card"|"digitalWallet").mount("#id").

Limite de autenticação (importante):

  • Pagamento do comprador (campos seguros e web-embeds do comprador) → sessionToken de POST /pay-ins/checkout.
  • Embeds da plataforma (unipaas.components: saldo, fatura, onboarding, payPortal, notificação) → o token de acesso /authorize com escopos + vendorId. O checkout do comprador não usa o token de acesso /authorize.

Após qualquer autorização no lado do cliente, verifique no servidor com GET /pay-ins/{authorizationId}; o status deve ser CAPTURED para sucesso.

Referências

  • references/auth.md — o fluxo /authorize, escopos, ciclo de vida do token, idempotência.
  • references/accept-payments.md — Produto Aceitar Pagamentos, os três níveis, a Página de checkout, criar-pagamento, tokenização, webhooks.
  • references/web-sdk.md — os dois caminhos de pagamento do comprador no lado do cliente alimentados pelo sessionToken.
  • references/security.md — manuseio de chaves, o que fica no servidor, a superfície de PCI.

Habilidades Relacionadas