01Todos os métodos numa só página
O checkout alojado coloca lado a lado cartões, Apple Pay, Google Pay e USDC. A encomenda 9F21-0716 fica à esquerda — três itens, uma taxa de processamento de €0.50, €49.00 a pagar — e a escolha do método à direita. O cliente escolhe; a página adapta-se; o comerciante integrou uma só vez.
- Botões de cartão, USDC e wallets no mesmo ecrã
- A encomenda completa — itens, taxas, total — junto ao formulário de pagamento
- Uma única ação Pay €49.00, qualquer que seja o método
02Mobile a partir do mesmo URL
O mesmo URL de checkout adapta-se ao telemóvel: a encomenda recolhe-se numa barra de resumo, os botões de método mantêm-se e o formulário do cartão conserva as etiquetas. O que funciona no desktop funciona no mobile — e quando quiser que o pagamento aconteça dentro da sua própria app, e não num browser, os SDKs iOS e Android apresentam o mesmo checkout de forma nativa sobre a mesma encomenda.
03Recibos que se explicam sozinhos
Pagar com USDC termina num recibo que o contabilista do comerciante consegue ler. Método: 52.95 USDC na Base →︎ liquidação em EUR, à taxa impressa no recibo, 1 EUR = 1.0807 USDC. Referência 9F21-0716, enviada por email ao cliente e descarregável na hora. O cliente pagou em crypto; a contabilidade regista €49.00.
04Um back office de links, não apenas links
Os payment links ganham uma secretária a sério: 8 links da Arc Studio SRL entre pagos, ativos e expirados, com montante, número de pagamentos e estado em cada linha. Os cartões em cima fazem a contagem — 4 links ativos, €2,304.50 cobrados este mês em 18 pagamentos por link, €49.00 pagos hoje. Criar, pesquisar, exportar, pronto.
- Cada link com o seu URL, montante e estado
- Cobrado no mês e pago hoje no topo
- Crie um link na mesma vista em que os acompanha
05Reembolsos sobre a encomenda
Um reembolso aponta para a encomenda, não para um método de pagamento. O painel abre em 9F21-0716 com o montante pré-preenchido com os €49.00 totais, um motivo obrigatório e uma nota opcional que segue para as exportações e para o recibo do cliente. Os fundos voltam automaticamente pelo mesmo canal do pagamento original — reembolsos de cartão para o cartão, encomendas em USDC como a respetiva liquidação em EUR — normalmente em 1–3 dias úteis.
- Total ou parcial — qualquer montante até ao valor cobrado
- Motivo obrigatório, nota enviada para o recibo
- O percurso original revertido automaticamente, em qualquer canal
A marca configura-se numa página de definições, não num projeto de serviços: carregue um logótipo, defina as cores de destaque, texto e fundo, escolha o tipo de letra e o estilo dos cantos. A pré-visualização em direto mostra o seu checkout real — desktop ou mobile — antes de guardar, e a cor de destaque define o foco do botão de pagamento, os ticks de estado e o separador ativo. Use o host de checkout atribuído com a sua sandbox ou o seu próprio domínio.
07Métodos que se ligam, não se constroem
Os métodos de pagamento são interruptores com providers por trás: cartões com 3-D Secure, Apple Pay e Google Pay como botões de wallet, 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 sem rodeios: os clientes veem a conversão antes de confirmar; você liquida sempre em EUR.
- Interruptor por método, com o provider indicado na linha
- Liquidação de USDC: conversão automática, pagamento diário às 23:00
- Routing de cartões com a política de 3-D Secure visível
08Integração drop-in
Crie uma encomenda, redirecione para a página alojada, receba o resultado. O Gateway trata da interface de pagamento, da lógica dos métodos e dos recibos. A sua equipa não tem de construir, corrigir nem manter atualizado nenhum frontend de checkout à medida que os métodos mudam.
09A encomenda é a unidade
Tudo assenta na encomenda, não no método de pagamento. A encomenda 9F21-0716 inclui os seus itens — um sprint de identidade de marca de €38.50, licenciamento de tipo de letra de €6.00, entrega urgente de €4.00 — uma taxa de processamento de €0.50 e um total. Seja qual for a forma de pagamento, essa referência é o que consulta, reconcilia e reembolsa.
10Configuração que não surpreende nenhuma sessão
As alterações a métodos e à marca aplicam-se às novas sessões de checkout — e isso é dito no ecrã onde as guarda. Um cliente a meio de um pagamento nunca vê a página mudar-lhe debaixo das mãos.
11Cartões, bem feitos
O fluxo de cartão é a parte aborrecida, resolvida: validação inline, 3-D Secure com autenticação forte do cliente integrada no fluxo sob uma política de routing legível, e cartões de teste por sandbox para as integrações. Aceitar crypto nunca piora o fluxo de cartão.
12Apple Pay e Google Pay
As wallets são botões, não projetos. Apple Pay e Google Pay surgem como janelas de um toque na mesma página e pagam com tokens do dispositivo — o número real do cartão nunca chega à página — pela mesma encomenda e com o mesmo recibo. Ativá-las é um interruptor no ecrã de métodos.
13USDC liquidado em EUR
A crypto é cotada a uma taxa mostrada no checkout e liquida em euros. O comerciante nunca fica com uma posição em tokens por acidente; a contabilidade mantém-se numa só moeda.
14USDC em três redes
O método USDC abrange Ethereum, Base e Solana atrás de um único interruptor. O cliente paga na rede onde tem a wallet; do lado do comerciante nada muda.
15Transferência bancária por vIBAN
O pagamento por transferência leva uma referência vIBAN, pelo que um pagamento SEPA recebido identifica a sua encomenda por construção. Ative-o para os clientes que querem uma fatura que possam pagar a partir do banco, e a reconciliação continua automática.
16Métodos locais onde fazem falta
Além de cartões e wallets, o checkout inclui os métodos account-to-account e locais que um comprador europeu espera encontrar, apresentados consoante o país do cliente e não despejados numa lista interminável.
17Buy now, pay later
O BNPL está na mesma linha de métodos que todos os outros — o cliente fraciona o pagamento, o comerciante recebe de uma só vez e a referência da encomenda não muda. Um interruptor, o mesmo recibo, a mesma reconciliação.
18Métodos que leem o cliente
A página ordena os métodos pelo que o cliente tem mais probabilidade 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.
19Preço na moeda do cliente, liquidação na sua
Mostre o montante na moeda do cliente, com a conversão indicada antes de confirmar, e liquide sempre em EUR. O cliente vê um valor familiar; o seu ledger mantém um só.
20Um checkout na língua do cliente
A página alojada localiza etiquetas, erros e recibos. Ninguém desiste de um pagamento porque o botão estava no idioma errado.
21Cartões guardados e one-click
Um cliente que regressa paga com um cartão guardado num só toque. O cartão fica em cofre do nosso lado e é referenciado por token, pelo que os seus sistemas guardam uma referência, nunca um PAN — e a segunda compra é mais curta do que a primeira.
22Subscrições e cobrança recorrente
As cobranças recorrentes seguem um calendário que define — montante, intervalo, início e fim — sobre um cartão tokenizado. Cada ciclo gera a sua própria encomenda e o seu próprio recibo, pelo que uma subscrição reconcilia linha a linha como tudo o resto.
23Retentativas que recuperam receita
Uma recusa temporária numa cobrança recorrente é repetida segundo um calendário em vez de ser dada como perdida, e o cliente só é avisado quando é preciso. As renovações falhadas deixam de ser churn silencioso.
24Network tokens e atualização de cartões
Os cartões guardados ficam como network tokens e acompanham o titular nas reemissões e nas renovações de validade. A subscrição que costumava falhar quando o cartão era substituído continua a cobrar.
25Uma API e uma área para developers
As encomendas são criadas por API com chaves de idempotência — um pedido repetido devolve o resultado original, nunca uma segunda cobrança — e a secção de developers reúne as chaves e a documentação. O checkout é alojado; a integração são meia dúzia de endpoints, documentados onde estão as definições.
26Webhooks no ciclo de vida da encomenda
O seu backend sabe dos pagamentos no instante em que acontecem: eventos de webhook assinados no ciclo de vida da encomenda — pago, falhado, reembolsado — com verificação de assinatura do seu lado e proteção contra replay do nosso.
27SDKs mobile para iOS e Android
As apps nativas apresentam o mesmo checkout dentro da app, sem enviar o utilizador para um browser. O SDK trata da lógica dos métodos, das janelas de wallet e do 3-D Secure; a encomenda e o recibo são os que o seu backend já conhece.
Os plugins de carrinho de compras ligam uma loja existente ao Gateway sem programador — instale, cole as chaves, faça um pagamento de teste. As encomendas chegam ao mesmo back office que as da API.
29Campos embebidos na sua própria página
Quando o pagamento tem de acontecer dentro do seu próprio layout, embeba os campos de pagamento diretamente: os inputs são alojados e abrangidos pelo PCI do nosso lado, a página à volta é inteiramente sua e os dados do cartão nunca passam pelos seus servidores.
30Utilização única, múltipla, expiração
Um link pode fechar após um pagamento ou continuar a cobrar — o lugar no workshop da demo já recebeu 3 pagamentos, a hora de consulta 6. Por defeito, os links expiram ao fim de 30 dias, e os links expirados dizem-no em vez de falharem em silêncio.
31Modo de teste
As integrações são testadas em sessões de teste, com os cartões emitidos juntamente com as chaves de sandbox, antes de qualquer movimento real. Os fluxos são idênticos, por isso o que passa em teste é o que vai para produção.
32Encaminhamento legível
O tráfego de cartões segue uma política de encaminhamento escrita em termos que reconhece — marca do cartão, país emissor, moeda, montante — e não uma caixa negra. Vê que rota um pagamento seguiu, no mesmo ecrã que mostra o pagamento.
33Uma segunda tentativa antes de perder a venda
Uma recusa temporária é repetida numa rota alternativa dentro da mesma sessão de checkout, antes de o cliente ver uma falha. A maioria dos pagamentos recuperados são pagamentos cujo risco o cliente nunca chegou a conhecer.
34Recusas em linguagem simples
Os códigos em bruto do emissor são traduzidos em motivos sobre os quais um operador pode agir — cartão expirado, saldo insuficiente, risco do emissor — e agrupados para que um padrão em vários pagamentos seja visível como padrão.
353-D Secure como política, não como atrito
A maioria dos pagamentos passa apenas com sinais do dispositivo e comportamentais; surge um desafio de autenticação adicional quando a política o exige. Define a política — sempre, baseada no risco, ou isento quando as regras o permitem — e a página alojada trata do fluxo.
36Uma linha para reconciliar
Checkout, recibo e liquidação partilham a mesma referência de encomenda. Quem procurar 9F21-0716 encontra um único registo de €49.00 — não um registo de cartão num sistema e um registo cripto noutro.
37Liquidação e transferências
A liquidação é definida onde a configura: conversão automática para EUR, liquidação para RO49 •••• 0421, transferência diária às 23:00. O valor que o contabilista vê amanhã é decidido hoje num ecrã que o comerciante consegue ler.
38Uma transferência rastreável
Cada transferência abre-se nas encomendas que a originaram, com as comissões discriminadas. A linha do banco corresponde a uma lista exportável, por isso o fecho do mês é uma consulta e não uma investigação.
39Reembolsos parciais
O valor do reembolso é editável até ao valor da cobrança original — a gaveta mostra o máximo e trata qualquer valor inferior como parcial. Dez reembolsos parciais sobre uma encomenda continuam a reconciliar-se com uma única referência.
40Motivos de reembolso registados
Cada reembolso exige um motivo e admite uma nota opcional, e a nota acompanha-o: aparece nas exportações e no recibo do cliente. Seis meses depois, ninguém precisa de se lembrar porque é que a encomenda 9F21-0716 foi compensada.
41Envio de recibos
Os recibos são enviados por e-mail ao cliente e podem ser descarregados na hora, e os recibos de reembolso seguem o mesmo caminho. O comerciante nunca cria um modelo de recibo.
42Anular antes da liquidação
Cancelar antes do lote do dia liberta a retenção da autorização e não há movimento de dinheiro — sem reembolso, sem comissão, sem nada no extrato do cliente para explicar.
43Controlos de risco ativos por defeito
Os pagamentos com cartão usam 3-D Secure sob uma política de encaminhamento legível. Os pagamentos por wallet levam a autenticação do próprio dispositivo, e os eventos de webhook têm a assinatura verificada antes de serem considerados fiáveis.
44Regras escritas à sua maneira
As regras de filtragem leem-se como frases — montante acima de X do país Y num cartão usado pela primeira vez — e agem em conformidade: permitir, desafiar ou bloquear. As listas de cartões, e-mails e moradas fiáveis e bloqueados estão no mesmo ecrã.
45Velocidade e sinais do dispositivo
Tentativas repetidas do mesmo cartão, dispositivo ou endereço são apanhadas por regras de frequência, e não por alguém que repara mais tarde. Os sinais aparecem no pagamento, não escondidos numa pontuação.
Um chargeback abre com a encomenda que lhe está associada: resultado da autorização, resultado do 3-D Secure, recibo, entrega, histórico de reembolsos. Responda a partir desse ecrã e o dossiê de provas é montado a partir do registo, não de memória.
47Os dados do cartão nunca chegam até si
A página que recolhe os dados do cartão é nossa, alojada e abrangida pelo PCI. Quer o cliente pague no nosso domínio, no seu ou dentro da sua app, os seus servidores veem um token e uma referência de encomenda — nunca um número de cartão.
48Encriptado em repouso, na UE
Os dados de pagamento são encriptados em repouso e processados na UE. Para um comerciante europeu, o local onde os dados residem é uma resposta, não uma nota de rodapé.
49Cada ação fica registada
Reembolsos, mudanças de método, alterações de marca, rotações de chaves — tudo fica registado num registo de auditoria com o operador, a data e hora e o motivo. As ações privilegiadas exigem um motivo antes de serem executadas.
50Perfis para quem precisa deles
A equipa financeira vê as transferências, o suporte vê as encomendas e emite reembolsos, os programadores veem chaves e logs. O acesso é atribuído por perfil, sem partilhar um único login.
51Um diretório de clientes
Os pagadores acumulam-se numa vista de clientes — quem pagou, com que frequência, por que método — para que um cliente recorrente seja um registo, e não uma coincidência de e-mails iguais nas exportações.
52Pesquisa e exportação CSV
Encontre um pagamento por link ou referência na caixa de pesquisa; exporte a vista atual para CSV quando a contabilidade precisar. O back office parte do princípio de que um contabilista 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 escolher. O suficiente para responder para onde foi o dinheiro e que método vale a pena promover — sem exportar nada.
54A vista do operador por trás
O Gateway liga-se ao Protocore Center: o back office de payment links aí mostra cada link com a transferência de liquidação associada e uma ligação para abrir no Tracer com o rasto completo. A sua equipa de operações vê através do checkout até ao ledger.
55Whitelabel ou powered-by
O checkout da demo pertence à Arc Studio SRL: o seu nome, a sua marca, a sua encomenda. Use-o com um rodapé powered-by-Protocore ou totalmente whitelabel — em ambos os casos, a página parece sua.
