_asseinfo

Olá, você poderia passar o manual? O link tá expirado. Muito obrigado.

Vou deixar aqui o fim da thread caso alguém mais tenha esta dúvida. Basta fazer um patch para a API mudando o status para REMOVIDA_PELO_USUARIO_RECEBEDOR. Endpoint: /cobv/{txid} Payload: { "status": "REMOVIDA_PELO_USUARIO_RECEBEDOR" } Muito obrigado

Estava lendo diretamente a documentação dos endpoints do BACEN. Vou baixar os fontes pra dar uma olhadinha. Muito obrigado pela orientação.

Eu não encontrei um endpoint específico para cancelamento. Seria fazer um patch enviando o status "REMOVIDA_PELO_USUARIO_RECEBEDOR"? Muito obrigado.

Olá?! Algumas vezes acontece do usuário registrar um pixcobv, enviar para o cliente dele e depois se arrepender por algum motivo bizarro. Recebemos um questionamento se não haveria uma forma de cancelar este Pix cobrança com vencimento para evitar que o cliente acabe pagando ele equivocadamente. Como vocês estão lidando com esta situação? Muito obrigado.

@JHONLENON obrigado por reforçar a mensagem lá para os caras. Eu estou com um ticket aberto com eles lá em Brasília com mais de 60 dias. Essa semana vou gravar um vídeo com os argumentos que havia te dito e mandar pra eles em um novo ticket. Vou também gravar como é o processo do Inter - com a geração do certificado digital por eles mesmo - pra ver a simplicidade. Pra gente aqui o Sicoob se tornou um pesadelo. Inclusive, suspendemos a liberação da rotina pra novos licenciados (e estamos perdendo algumas vendas por conta disso). Tivemos até gerente desinformando dando uma de técnico de informática para o nosso cliente e dizendo que nosso software é inseguro porque não temos IP fixo . O mesmo cara que oferece título de capitalização como investimento é o mesmo que agora é especialista em segurança digital . Haja paciência.

@JHONLENON putz! Que oportunidade, cara. A melhor maneira desse problema ser resolvido seria eles facilitando esse processo. Nós temos software web há 8 anos e emitimos boletos via API há 4,5 anos via PJBank (fará cinco agora no mês 7). Temos integração com diversos bancos e o mais sofrido é o Sicoob (temos também outro software Desktop com 21 anos - usando acbr). Nós implementamos a V1 com o fluxo de autenticação antigo e temos diversos licenciados rodando. Foi bem chatinho de fazer. Em nossa avaliação o novo fluxo de autenticação é um tiro no pé do próprio banco. Eis alguns motivos: a. Nem todo fornecedor de ERP tem experiência com web. Vários irão pelo caminho de fazer diretamente no desktop. Isso fará com que o custo do IP fixo + certificado acabe caindo para o licenciado. A gente sabe que muitos correntistas que optam pelo Sicoob é pelo baixo preço do boleto. b. Quem se aventurar em montar um servidor web para fazer o papel de proxy entre o banco e o ERP desktop terá que ter cuidado redobrado com o aplicativo. Se a pessoa não tiver experiência, pode acabar deixando brechas para ataques. Sem contar que esse software precisa ser constantemente atualizado - frameworks envelhecem rápido. Lembrando que o certificado A1 provavelmente terá que ficar nessa máquina para assinar o request. A web não é brincadeira - ainda mais quando se trata de transações financeiras. c. Acreditamos que a explosão de IP fixos pode ser bem chato para o firewall do banco no futuro. d. Mesmo nós que estamos na web, ter IP fixo é chato. A gente trabalha com elastic cloud e nunca sabemos os IPs e nem mesmo quantos servidores estão rodando. Teremos que alugar um IP fixo e tunelar nossa comunicação com o Sicoob através dele. Entendemos que o banco precisa de segurança, mas acreditamos que existem outros meios mais acessíveis pra isso. Um exemplo é o Banco Inter. Você mesmo emite o certificado no Internet Banking deles e o IP fixo não é requerido. Seria muito parecido com o novo fluxo do Sicoob. Se for do seu interesse, eu posso até gravar um vídeo falando sobre o que eu escrevi acima. Muito obrigado.

A gente até vem conseguindo a liberação do uso da V1, mas é um inferno . Eu estou me organizando aqui pra colocar um par de devs pra reescrever nossa integração pra V2. O que mais está nos ferrando mesmo é essa exigência maluca de ter um IP fixo para liberar no firewall dos caras. Vamos ter que ter uma infra adicional por conta disso (e custos desnecessários). É uma pena o suporte deles ser tão omisso. Não tem nem chance de conversar com ninguém a respeito do problema, pois eles só respondem o que é conveniente. Outro pé no saco é que só vai dar pra atender quem tem A1. Depois eu vou fazer um teste se o certificado precisa ser do correntista ou se ele usa somente para certificar o autor da comunicação (como acontece na NF-e: o XML precisa ser assinado pelo certificado do emissor, mas a transmissão pode ser feita com o certificado de um terceiro). Se o certificado só servir para a comunicação então aqui nós podemos usar o da própria softhouse. Assim, licenciados que possuem o A3 não ficarão na mão. Vamos trocando uma ideia por aqui.

@JHONLENON bucha, cara.

Olá?! Não sei se alguém aqui tentou recentemente credenciar algum correntista no Sicoob, mas agora os caras não estão mais aceitando via Authorization Code. Pelo que vimos, tem que usar a V2 e Client Credential. Temos clientes em várias partes do país e as agências, no geral, não sabem ao certo o que fazer. Duas coisas que ferram o uso do Client Credential: a. Precisa ter um certificado digital b. Precisa ter um IP fixo para cadastrar no firewall do banco. O suporte dos caras é bem complicado. Você escreve pra lá, o ticket é aberto e simplesmente ninguém responde. Nossos clientes que ainda usam o Authorization Code estão funcionando sem problema. O credenciamento de novos correntistas não estamos mais conseguindo fazer. Alguém está passando por dificuldades com eles também? Muito obrigado.

Olá pessoal, enfrentamos esse problema ontem o dia todo também. Nosso problema acontece com a emissão de NF-e em SC. Recomendo reportarem de forma profissional e séria junto a SEFAZ DE SC, usando o formulário http://caf2.sef.sc.gov.br/Views/Shared/NovoTicket.aspx. Acredito que se todos reportarem problemas, eles vão investigar novamente. Na outra vez, tinha problemas e foram resolvidos. Abraços e bom trabalho.

Olá galera, recebi a resposta da SEFAZ de SC. Era problema com o webservice mesmo. Imagem:

Olá pessoal, se vocês estão com problemas (HTTP error (403)) em SC também, seria legal reportar no formulário do link abaixo: http://caf2.sef.sc.gov.br/Views/Shared/NovoTicket.aspx Até mais.

Estou enfrentando o mesmo problema. Alguém já encontrou algum padrão? Aqui só estou tendo problemas em SC.

Muito obrigado @oraculum, sua resposta foi de grande ajuda. Abraço!