01Todos os meios em uma página
O checkout hospedado coloca cartões, Apple Pay, Google Pay e USDC lado a lado. O pedido 9F21-0716 fica à esquerda — três itens, taxa de processamento de €0.50, €49.00 a pagar — e a escolha do meio de pagamento à direita. O cliente escolhe, a página se adapta e o lojista integrou uma única vez.
- Botões de cartão, USDC e carteiras na mesma tela
- O pedido completo — itens, taxas, total — ao lado do formulário de pagamento
- Uma única ação Pay €49.00, qualquer que seja o meio
02Mobile a partir da mesma URL
A mesma URL de checkout se reorganiza em layout de celular: o pedido vira uma barra de resumo, os botões de pagamento continuam no lugar e o formulário de cartão mantém seus rótulos. O que vai para o desktop vai para o mobile — e quando você quer que o pagamento aconteça dentro do seu próprio app, e não num navegador, os SDKs para iOS e Android apresentam o mesmo checkout de forma nativa, sobre o mesmo pedido.
03Recibos que se explicam sozinhos
Pagar com USDC termina num recibo que o contador do lojista consegue ler. Meio: 52.95 USDC na Base →︎ liquidação em EUR, na cotação impressa no recibo, 1 EUR = 1.0807 USDC. Referência 9F21-0716, enviada por e-mail ao cliente e disponível para download na hora. O cliente pagou em cripto; a contabilidade registra €49.00.
04Um back office de links, não só links
Links de pagamento ganham uma mesa de trabalho de verdade: 8 links da Arc Studio SRL entre pagos, ativos e expirados, com valor, número de pagamentos e status em cada linha. Os cards no topo mostram o placar — 4 links ativos, €2,304.50 recebidos no mês em 18 pagamentos por link, €49.00 pagos hoje. Criar, buscar, exportar, pronto.
- Cada link com sua URL, valor e status
- Recebido no mês e pago hoje no topo
- Crie um link na mesma tela em que você os acompanha
05Reembolsos sobre o pedido
O reembolso aponta para o pedido, não para um meio de pagamento. O painel abre em 9F21-0716 com o valor pré-preenchido com os €49.00 integrais, um motivo obrigatório e uma observação opcional que vai para as exportações e para o recibo do cliente. Os fundos voltam automaticamente pelo mesmo trilho do pagamento original — reembolsos de cartão para o cartão, pedidos em USDC como a liquidação em EUR — normalmente em 1–3 dias úteis.
- Total ou parcial — qualquer valor até o da cobrança original
- Motivo obrigatório, observação levada ao recibo
- A rota original é desfeita automaticamente, em qualquer trilho
Branding é uma página de configurações, não um projeto de serviços: envie um logo, defina as cores de destaque, texto e superfície, escolha a fonte e o estilo dos cantos. A prévia ao vivo renderiza o seu checkout de verdade — desktop ou mobile — antes de você salvar, e a cor de destaque define o foco do botão de pagar, os checks de status e a aba ativa. Rode no host de checkout emitido com o seu sandbox ou no seu próprio domínio.
07Meios que você liga, não que você constrói
Os meios de pagamento são chaves liga/desliga com provedores por trás: cartões com 3-D Secure, Apple Pay e Google Pay como botões de carteira, USDC em Ethereum, Base e Solana, transferência bancária SEPA por referência vIBAN. Ao lado, o painel de liquidação diz as regras com clareza: o cliente vê a conversão antes de confirmar; você sempre recebe em EUR.
- Chave por meio de pagamento, com o provedor indicado na linha
- Liquidação de USDC: conversão automática, repasse diário às 23:00
- Roteamento de cartões com a política de 3-D Secure visível
08Integração drop-in
Crie um pedido, redirecione para a página hospedada, receba o resultado. O Gateway cuida da interface de pagamento, da lógica dos meios e dos recibos. Não há frontend de checkout para o seu time construir, corrigir ou manter atualizado a cada mudança nos meios de pagamento.
09O pedido é a unidade
Tudo gira em torno do pedido, não do meio de pagamento. O pedido 9F21-0716 traz seus itens — um sprint de identidade de marca de €38.50, licenciamento de fonte de €6.00, entrega urgente de €4.00 —, uma taxa de processamento de €0.50 e um único total. Seja qual for a forma de pagamento, essa referência é o que você consulta, concilia e reembolsa.
10Configuração que não surpreende uma sessão
Mudanças de meios e de branding valem para as novas sessões de checkout — e isso está dito na tela em que você salva. Um cliente no meio do pagamento nunca vê a página mudar sob seus dedos.
11Cartões, do jeito certo
O caminho do cartão é a parte chata, resolvida: validação inline, 3-D Secure com autenticação forte do cliente embutida no fluxo, sob uma política de roteamento legível, e cartões de teste por sandbox para as rodadas de integração. Aceitar cripto nunca piora o fluxo de cartão.
12Apple Pay e Google Pay
As carteiras são botões, não projetos. Apple Pay e Google Pay aparecem como telas de um toque na mesma página e pagam com tokens do dispositivo — o número real do cartão nunca chega à página —, pelo mesmo pedido e com o mesmo recibo. Ativá-las é uma chave na tela de meios de pagamento.
13USDC liquidado em EUR
A cripto é cotada a uma taxa exibida no checkout e liquidada em euros. O lojista nunca acaba com uma posição em token por acidente; a contabilidade fica numa única moeda.
14USDC em três redes
O meio USDC cobre Ethereum, Base e Solana atrás de uma única chave. O cliente paga na rede em que sua carteira está; para o lojista, nada muda.
15Transferência bancária por vIBAN
O pagamento por transferência leva uma referência vIBAN, então um pagamento SEPA recebido identifica o pedido por construção. Ative para os clientes que querem uma fatura paga pelo banco, e a conciliação continua automática.
16Meios locais onde importam
Além de cartões e carteiras, o checkout traz os meios locais e de conta a conta que o comprador europeu espera encontrar, apresentados conforme o país do cliente em vez de despejados numa lista longa.
17Compre agora, pague depois
O BNPL fica na mesma linha de meios que todo o resto — o cliente parcela o pagamento, o lojista recebe uma vez só e a referência do pedido não muda. Uma chave, o mesmo recibo, a mesma conciliação.
18Meios que leem o cliente
A página ordena os meios pelo que o cliente tem mais chance de usar — país, idioma, dispositivo e se já pagou antes — para que a opção relevante seja a primeira, e não a quarta.
19Cotado na moeda dele, liquidado na sua
Mostre o valor na moeda do cliente, com a conversão informada antes de ele confirmar, e liquide sempre em EUR. O cliente vê um número familiar; o seu ledger mantém um só.
20Um checkout no idioma dele
A página hospedada localiza seus rótulos, erros e recibos. Ninguém abandona um pagamento porque o botão estava no idioma errado.
21Cartões salvos e um clique
O cliente recorrente paga com um cartão salvo em um toque. O cartão fica no cofre do nosso lado e é referenciado por token, então seus sistemas guardam uma referência, nunca um PAN — e a segunda compra é mais curta que a primeira.
22Assinaturas e cobrança recorrente
As cobranças recorrentes seguem um calendário que você define — valor, intervalo, início e fim — sobre um cartão tokenizado. Cada ciclo gera seu próprio pedido e seu próprio recibo, então a assinatura é conciliada linha a linha como todo o resto.
23Novas tentativas que recuperam receita
Uma recusa temporária numa cobrança recorrente é retentada em um calendário em vez de ser dada como perdida, e o cliente só é avisado quando isso importa. Renovações que falham deixam de ser churn silencioso.
24Network tokens e atualização de cartões
Os cartões salvos são mantidos como network tokens e acompanham o titular em reemissões e vencimentos. A assinatura que antes quebrava quando o cartão era trocado continua cobrando.
25Uma API e uma área para desenvolvedores
Os pedidos são criados via API com chaves de idempotência — uma requisição repetida devolve o resultado original, nunca uma segunda cobrança — e a seção de desenvolvedores reúne as chaves e a documentação. O checkout é hospedado; a integração são alguns endpoints, documentados onde ficam as configurações.
26Webhooks no ciclo de vida do pedido
Seu backend fica sabendo dos pagamentos no instante em que acontecem: eventos de webhook assinados no ciclo de vida do pedido — pago, falho, reembolsado — com verificação de assinatura do seu lado e proteção contra replay do nosso.
27SDKs mobile para iOS e Android
Apps nativos apresentam o mesmo checkout dentro do app, sem jogar o usuário para um navegador. O SDK traz a lógica dos meios, as telas das carteiras e o 3-D Secure; o pedido e o recibo são os mesmos que o seu backend já conhece.
Plugins de carrinho de compras conectam uma loja existente ao Gateway sem desenvolvedor — instale, cole as chaves, faça um pagamento de teste. Os pedidos caem no mesmo back office que os criados via API.
29Campos embutidos na sua própria página
Quando o pagamento precisa acontecer dentro do seu próprio layout, incorpore os campos de pagamento diretamente: os inputs são hospedados e ficam no escopo PCI do nosso lado, a página ao redor é toda sua e os dados do cartão nunca tocam os seus servidores.
30Uso único, uso múltiplo, expiração
Um link pode se encerrar após um pagamento ou continuar recebendo — a vaga de workshop da demo recebeu 3 pagamentos, a hora de consultoria, 6. Por padrão, os links expiram automaticamente após 30 dias, e os expirados avisam isso em vez de falhar em silêncio.
31Modo de teste
As integrações rodam em sessões de teste, com os cartões emitidos junto com suas chaves de sandbox, antes de qualquer valor real se mover. Os fluxos são idênticos: o que passa no teste é o que vai para produção.
32Roteamento que você consegue ler
O tráfego de cartões segue uma política de roteamento escrita em termos que você reconhece — bandeira, país emissor, moeda, valor — e não uma caixa-preta. Você vê qual rota o pagamento seguiu, na mesma tela que mostra o pagamento.
33Uma segunda tentativa antes de perder a venda
Uma recusa temporária é retentada em uma rota alternativa dentro da mesma sessão de checkout, antes de o cliente ver uma falha. A maioria dos pagamentos recuperados são aqueles que o cliente nunca soube que estavam em risco.
34Recusas em linguagem clara
Códigos brutos do emissor viram motivos sobre os quais o operador pode agir — cartão vencido, saldo insuficiente, risco do emissor — e são agrupados para que um padrão em vários pagamentos apareça como padrão.
353-D Secure como política, não como atrito
A maioria dos pagamentos passa apenas com sinais de dispositivo e comportamento; um desafio adicional aparece quando a política exige. Você define a política — sempre, baseada em risco ou isenta onde as regras permitem — e a página hospedada conduz o fluxo.
36Uma linha para conciliar
Checkout, recibo e liquidação carregam a mesma referência de pedido. Quem buscar 9F21-0716 encontra um único lançamento de €49.00 — e não um registro de cartão em um sistema e um de cripto em outro.
37Liquidação e repasses
A liquidação é definida onde você a configura: conversão automática para EUR, liquidação em RO49 •••• 0421, repasse diário às 23:00. O número que o contador vê amanhã é decidido hoje, em uma tela que o lojista consegue ler.
38Um repasse rastreável até a origem
Cada repasse se abre nos pedidos que o originaram, com as tarifas detalhadas. A linha do banco bate com uma lista exportável, então o fechamento do mês é uma consulta, não uma investigação.
39Reembolsos parciais
O valor do reembolso é editável até o limite da cobrança original — o painel mostra o máximo e trata qualquer valor menor como parcial. Dez reembolsos parciais de um mesmo pedido continuam conciliando com uma única referência.
40Motivos de reembolso registrados
Todo reembolso tem um motivo obrigatório e uma observação opcional, e a observação acompanha: aparece nas exportações e no recibo do cliente. Seis meses depois, ninguém precisa lembrar por que o pedido 9F21-0716 foi ressarcido.
41Envio de recibos
Os recibos são enviados por e-mail ao cliente e podem ser baixados na hora; os recibos de reembolso seguem o mesmo caminho. O lojista nunca precisa criar um modelo de recibo.
42Cancelamento antes da liquidação
Cancelar antes do lote do dia libera o bloqueio da autorização e nenhum dinheiro se move — sem reembolso, sem tarifa, sem nada na fatura do cliente para explicar.
43Controles de risco ativos por padrão
Pagamentos com cartão passam por 3-D Secure sob uma política de roteamento que você consegue ler. Pagamentos por carteira trazem a autenticação do próprio dispositivo, e os eventos de webhook têm a assinatura verificada antes de serem aceitos.
44Regras escritas do seu jeito
As regras de triagem se leem como frases — valor acima de X vindo do país Y em um cartão novo — e agem sobre elas: permitir, desafiar ou bloquear. Listas de cartões, e-mails e endereços confiáveis e bloqueados ficam na mesma tela.
45Velocidade e sinais de dispositivo
Tentativas repetidas de um mesmo cartão, dispositivo ou endereço são barradas por regras de frequência, e não por alguém que repare depois. Os sinais aparecem no pagamento, não escondidos em um score.
Um chargeback já abre com o pedido por trás: resultado da autorização, desfecho do 3-D Secure, recibo, entrega, histórico de reembolsos. Responda a partir dessa tela, e o dossiê de evidências é montado a partir do registro, não da memória.
47Dados de cartão nunca chegam até você
A página que coleta os dados do cartão é nossa, hospedada e dentro do escopo PCI. Seja no nosso domínio, no seu ou dentro do seu app, seus servidores veem um token e uma referência de pedido — nunca um número de cartão.
48Criptografado em repouso, na UE
Os dados de pagamento são criptografados em repouso e processados na UE. Para um lojista europeu, onde os dados ficam é uma resposta, não uma nota de rodapé.
49Cada ação registrada
Reembolsos, trocas de método, mudanças de marca, rotações de chave — tudo é gravado em uma trilha de auditoria com o operador, o horário e o motivo. Ações privilegiadas exigem um motivo antes de serem executadas.
50Perfis para quem precisa
O financeiro vê repasses, o suporte vê pedidos e faz reembolsos, os desenvolvedores veem chaves e logs. O acesso é concedido por perfil, e não por um login compartilhado.
51Um diretório de clientes
Os pagadores se acumulam em uma visão de clientes — quem pagou, com que frequência, por qual método — para que um cliente recorrente seja um registro, e não uma coincidência de e-mails iguais nas exportações.
52Busca e exportação em CSV
Encontre um pagamento por link ou referência na caixa de busca; exporte a visão atual em CSV quando a contabilidade pedir. O back office parte do princípio de que um contador vai perguntar.
53Os números, por dia e por método
Volume, taxa de aprovação, reembolsos e mix de métodos, no período que você escolher. O suficiente para responder para onde o dinheiro foi e qual método vale promover — sem exportar nada.
54A visão do operador por trás
O Gateway se conecta ao Protocore Center: o back office de links de pagamento ali mostra cada link com sua transferência de liquidação anexada e um link para abrir no Tracer com o rastro completo. Sua equipe de operações enxerga do checkout até o ledger.
55Whitelabel ou powered-by
O checkout da demo pertence à Arc Studio SRL: o nome, a marca e o pedido são deles. Rode com um rodapé powered-by-Protocore ou totalmente whitelabel — de qualquer forma, a página parece sua.
