O Pix por aproximação já foi “quase cartão”: encosta, confirma e segue o baile. O problema é que, na experiência do usuário, a reprovação por saldo insuficiente vira um mini trauma — porque só dá pra descobrir depois que você tentou. Segundo o Tecnoblog.net, agora existe um complemento: exibir o saldo (e limites) antes do pagamento, o que reduz falhas e melhora a confiança na jornada. E, para devs, a parte interessante é que isso depende diretamente do Open Finance e de uma “jornada otimizada” que mudou o fluxo de consentimento e coleta de dados.
Pix por aproximação com prévia de saldo: o que muda de verdade?
O Pix por aproximação funciona como uma compra por proximidade (via carteira digital), mas com comportamento transacional do Pix. Em termos simples: o pagamento não será autorizado se não houver dinheiro suficiente em conta.
Antes, a pessoa só percebia se daria certo no momento de autorizar (ou ao final do processo). Agora, com o recurso novo, a app pode mostrar previamente informações como:
- Saldo disponível
- Limite de valor para transações
- Probabilidade/possibilidade de concluir a operação via Pix
Isso é disponibilizado oficialmente “desde o início da semana”, mas o detalhe que o Tecnoblog.net destaca é crucial: o saldo só é exibido se o usuário optar por esse recurso. Na prática, isso implica em um consentimento/fluxo extra via Open Finance.
Por que o Open Finance é o motor dessa feature?
O ponto técnico aqui não é “magia no app”. É dados + consentimento + decisão de UX.
Para mostrar saldo e limite antes do pagamento, a carteira precisa de informações do participante (banco ou instituição de pagamento). E esse acesso acontece via Open Finance.
O que mudou com a “jornada otimizada”
Segundo o Tecnoblog.net, até recentemente o consentimento para compartilhar informações como saldo e limite e o consentimento para vincular conta a serviço de pagamentos eram feitos separadamente.
A atualização do Open Finance unifica esses procedimentos. Em outras palavras: ao autorizar pagamentos pela conta, o usuário pode optar por também compartilhar informações como saldo e limite.
O “porquê” técnico/arquitetural por trás disso é bem prático:
- Menos etapas reduz abandono na jornada.
- Menos reautorizações evita fricção e melhora conversão.
- Coleta mais previsível permite que a UX antecipe bloqueios antes da tentativa.
Como isso afeta o fluxo no aplicativo da carteira digital?
O Tecnoblog.net descreve dois caminhos típicos para ativação:
- Conectar uma conta bancária ou de pagamento a uma carteira digital e habilitar o compartilhamento.
- Autorizar movimentações automáticas via Open Finance.
Essas ações podem ser executadas no app da instituição financeira onde a pessoa tem conta.
Depois que a ativação acontece, a pessoa passa a conseguir consultar via app da Carteira Digital, por exemplo:
- se existe saldo suficiente
- qual o limite disponível para transações
- se o pagamento provavelmente será concluído via Pix
Implicações práticas: menos falhas, mas mais atenção a consentimento e cache
Do ponto de vista de produto e engenharia, essa feature puxa duas responsabilidades extras para quem implementa integrações:
- Consentimento granular: sem opt-in explícito, você não exibe saldo. Logo, precisa lidar com estados “sem permissão”.
- Sincronia de dados: saldo e limite podem mudar entre a prévia e o momento do pagamento (ou mesmo por concorrência no backend). Você precisa decidir se sua UI é “informativa” ou “garantidora”.
Na minha experiência, quando apps entram em “modo pré-aprovação”, a tentação é prometer demais. E isso vira bug ou reclamação quando, por qualquer motivo, o saldo muda justo depois.
Comparando com alternativas reais (e por que essa é melhor)
Você poderia imaginar outros jeitos de reduzir tentativa falha:
- Mostrar saldo manualmente em outra tela (tipo “ver extrato”) — funciona, mas adiciona passo e cansa o usuário.
- Fazer tentativa e mostrar erro (fluxo antigo) — simples de implementar, mas ruim de UX e com custo reputacional.
- Checar por API própria (sem Open Finance) — em geral é impossível, porque o saldo está no sistema do participante, não no seu.
A opção do Open Finance é a mais alinhada porque traz dados “de verdade” do participante. E a “jornada otimizada” reduz a penalidade de consentimento.
Na Prática: como eu pensaria o fluxo técnico (com exemplo funcional)
Vou descrever um fluxo que uma carteira/serviço de pagamento poderia seguir para exibir saldo antes do Pix por aproximação. Não é “copiar e colar”, mas é bem fiel ao que devs precisam modelar.
Passo a passo (estados e decisões)
- Usuário inicia pagamento por aproximação no app.
- App verifica se existe consentimento ativo para consultar saldo e limite via Open Finance.
- Se existir consentimento:
- App chama o provedor Open Finance para obter saldo e limites.
- Calcula uma decisão de UX: “pode concluir agora” vs “provável que falhe”.
- Mostra na tela antes do usuário confirmar.
- Se não existir consentimento:
- App não exibe saldo prévio (ou exibe um aviso: “habilite nas configurações”).
- Segue para a tentativa normal de pagamento.
- Após prévia e confirmação, o pagamento é executado no fluxo do Pix.
- Se falhar por saldo insuficiente (condição de corrida), o app trata como falha legítima e oferece caminho: “tente outro valor”, “repasse”, “recarregue”.
Exemplo de código (Node.js/TypeScript) para decisão de prévia
O código abaixo modela a lógica de “se tenho consentimento, consulto; senão, não consulto”. O formato exato das APIs do Open Finance depende do participante/provedor, mas a estrutura de decisão e tratamento de erros é a parte que devs realmente acertam (ou erram).
type Consent = {
hasBalanceScope: boolean;
expiresAt: Date;
};
type BalanceResponse = {
balanceAvailable: number; // ex: em centavos
limitForPix: number; // ex: em centavos
};
type PreviewDecision = {
status: "CAN_PAY" | "CANNOT_PAY" | "UNKNOWN";
reason?: string;
};
function canUsePreview(consent: Consent | null): boolean {
if (!consent) return false;
const now = new Date();
const isNotExpired = consent.expiresAt > now;
return consent.hasBalanceScope && isNotExpired;
}
function decidePreview(amount: number, data: BalanceResponse): PreviewDecision {
if (data.balanceAvailable < amount) {
return { status: "CANNOT_PAY", reason: "Saldo insuficiente" };
}
if (data.limitForPix < amount) {
return { status: "CANNOT_PAY", reason: "Limite para Pix insuficiente" };
}
return { status: "CAN_PAY" };
}
// Exemplo de função “orquestradora” (consulta + decisão)
async function getPreviewOrFallback(args: {
consent: Consent | null;
amount: number;
fetchBalance: () => Promise<BalanceResponse>;
}): Promise<PreviewDecision> {
const { consent, amount, fetchBalance } = args;
if (!canUsePreview(consent)) {
// Sem consentimento: não mostramos saldo prévio como "fonte de verdade"
return { status: "UNKNOWN", reason: "Sem permissão para consultar saldo/limite" };
}
try {
const data = await fetchBalance(); // chamada Open Finance (abstrata)
return decidePreview(amount, data);
} catch (err) {
// Erro de rede/timeout/provedor: prefere manter UX estável a “quebrar”
return { status: "UNKNOWN", reason: "Não foi possível consultar saldo/limite agora" };
}
}O porquê dessas decisões:
- Status UNKNOWN evita mentir ao usuário. Em prévia de saldo, “falso positivo” é pior que “sem prévia”.
- Consentimento expirado: é comum esquecer TTL/expiração e exibir dados sem escopo válido.
- Tratamento de erro: provedor pode falhar; você não quer travar a compra inteira.
Erros Comuns (o que eu já vi dar ruim em produção)
1) Tratar prévia como garantia (em vez de estimativa)
Mesmo com saldo e limite, pode haver diferença entre o momento da consulta e o momento do débito. Isso acontece por concorrência, atualizações, regras internas do participante, etc. O app deve comunicar com cuidado.
2) Não modelar estados de consentimento
Dev apressado pensa “uma vez que conectou, sempre vai funcionar”. Não. Consentimento pode expirar, mudar escopo, ser revogado.
Resultado típico: o app tenta consultar e cai em erro. O tratamento precisa ser degradável.
3) Cache sem invalidar
Se você cacheia saldo para reduzir chamadas, precisa definir política de expiração curta. Cache “para sempre” cria a pior UX: mostrar “pode pagar” quando já não pode.
4) Unidade/escala errada (centavos vs reais)
Isso é clássico. Se seu backend trabalha com centavos e sua UI com reais (ou vice-versa), o cálculo de saldo/limite vai ficar errado e o recurso perde credibilidade rapidamente.
5) Misturar limitações de UX com regras de negócio
Exibir ou não saldo é UX, mas decidir “pode pagar” depende de regra. Misturar isso em componentes visuais dificulta teste e manutenção.
FAQ: dúvidas que devs realmente fazem
1) Precisa fazer isso no app do lojista?
Não necessariamente. O fluxo descrito envolve a carteira digital (onde o usuário configura consentimento e onde a prévia aparece). O lojista tende a receber apenas o resultado do Pix, como sempre.
2) Se o usuário não optar pelo recurso, o pagamento ainda funciona?
Funciona. A mudança é na experiência prévia. Sem opt-in, a app não consulta saldo/limite para exibir antes, e o usuário segue com o fluxo padrão.
3) Como evitar “saldo desatualizado” aparecendo na tela?
Use expiração curta para dados consultados, aplique fallback para UNKNOWN em caso de erro, e trate a prévia como “verificação” — não como garantia absoluta.
4) Qual é o impacto disso em métricas (conversão e falha de pagamento)?
Tende a reduzir tentativas que falham por saldo/limite e aumenta confiança. Mas também pode diminuir conversão se o consentimento for difícil (por isso a “jornada otimizada” importa tanto).
5) Dá para implementar sem Open Finance?
Na prática, não da forma genérica. O saldo e limite residem na esfera do participante. Sem Open Finance (ou um contrato equivalente), você não tem acesso confiável a essas informações.
O que eu recomendo para quem vai integrar ou desenhar a feature
- Trate consentimento como dependência do recurso, não como detalhe.
- Modele a prévia como estado (CAN_PAY / CANNOT_PAY / UNKNOWN).
- Tenha fallback para garantir que a jornada de pagamento não trave.
- Escreva testes para unidade de valor, expiração e cenários de falha do provedor.
Segundo o Tecnoblog.net, a novidade chegou com o objetivo de deixar o Pix por aproximação mais “cartão-like”, só que sem autorizar quando faltar saldo. O ganho aqui é direto: o usuário vê antes, e o sistema evita surpresa.
Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.