Termos mais procurados:
Boa tarde pessoal! Trago para vocês um novo endpoint, o envio de Pix já disponível em nossa documentação https://dev.gerencianet.com.br/docs#section-requisitar-envio-de-pix-.
Para a sua utilização é necessário entrar em contato com a nossa equipe comercial por qualquer um dos canais oficiais (https://gerencianet.com.br/artigo/entrar-em-contato/) e assinar um termo contratual, mais detalhes sobre o termo vocês conseguem com a própria equipe comercial.
@Rubens Kuhl#9323 , vi você perguntando sobre a confirmação de pagamento de boleto na CIP. Eu vi que a PagHiper oferece essa notificação. Mas eles alegam que não é garantido que você vá receber o dinheiro e só serve pra antecipar a preparação de envio de um produto, por exemplo (sem efetivamente enviá-lo até a confirmação da compensação).
Você sabe me dizer em quais casos o recebimento poderia não se concretizar, ou poderia me indicar documentação a respeito? Obrigado
na documentação da gn tem o comando pra converter o .p12 pra .pem
e a documentação que to seguindo
igual documentação
Putz, tem mais isso, é que eu estava lendo a documentação antiga. Valew 🙂
Boa tarde! No Pix utilizamos o webhook, com o mTLS seguindo as normas do BACEN. Mais detalhes aqui em nossa documentação https://dev.gerencianet.com.br/docs#section-webhook
Textos informativos deveriam ir no array infoAdicionais e não no solicitacaoPagador. Se admite-se um pagamento sem a entrada do dado por parte do usuário, se torna informativo (não fica claro que o preenchimento é opcional quando presente, pela documentação, diz que a presença do campo é opcional)
como a documentação diz, é opcional
No caso seria o pagador, que estou comentando, não estou usando e está dando certo sem ele no modo teste.
Na documentação diz ser opcional.
o campo recebedor é obrigatório no qr code mas a documentação admite qualquer valor inócuo, como "Pix". vocês poderiam simplificar isso enormemente. além de ser mais privativo (Privacy by Design)
na verdade, a documentação da GN está dúbia, tem "Sucesso(200)" no rótulo, e 201 na aba do quadro de response.
De fato, deveria ser 201. Não apenas pela documentação atual do BACEN (que não sei se mudou recentemente nesse aspecto) mas pela documentação da própria GN.
Para quem for ou vai utilizar o endpoint do webhook em produção do PUT da url de retorno, na documentação tem esta url https://api-pix-h.gerencianet.com.br/v2/webhook/:chave
Porém, para funcionar precisamos retirar os dois pontos antes da palavra" :chave" e claro a própria palavra "chave" ficando assim = https://api-pix.gerencianet.com.br/v2/webhook/---- no caso este é um exemplo com uma chave aleatoria, as demais chaves utlizem o que o manual recomenda 🙂 Substituir o por seus dados.
Na documentação e no postman tem uma parte chamada de PIX que possuem os endpoints para a devolução .
Na documentação da GN está minúsculo mesmo, mas na descrição do parâmetro tem essa nota "Na pacs.008, é referenciado como TransactionIdentification ou idConciliacaoRecebedor. ". Como na nota informa txId, testei com o i maiúsculo e retornou o dado esperado, enquanto com minúsculo sempre retornava nulo
Pelo que a GN já falou, estão com a documentação ja e deverão implementar em algum tempo
ok, é que eu não tinha prestado atenção no true. Ai fiquei na cabeça com o retorno $webhook->parametro e é $webhook['parametro'] 🙂 Com a nova documentação mudou a maioria das posições dos array que tinha aqui feito, estou mudando os create para o db.
Não citei THE BIBLE, trata-se de meus princípios de confiança em nossos semelhantes. 😉 Estou implementando o retorno do webhook 🙂 Capítulo mudar os parametros do json para a documentação nova. 🙂
Não ví isso ainda na documentação da GN de entregar o cartão e ainda cortado ao meio, coisa que ele pode muito bem colar com superbond e usar normalmente, pois ficou com o chip, a não ser se o cartão seja contact less, que vai danificar a antena receptora de RF ao cortar. E outra eu não compro nada a carteiros, eles apenas são meus entregadores, por que eu deveria fazer a carta ? 🙂
