Histórico de mensagens sobre url POST em cartões

pessoal, uma duvida "conceitual"
como via jquery eu ficarei bom boa parte dos dados expostos (ao obter o installments por exemplo), obviamente que qualquer 'sobrinho' pode entender a lógica por trás da camada de tela e tentar burlar alguns payloads que só receberei em tempo de tela (não me refiro ao payment_token).
Como eu obtive installment, value e interest_percentage em tempo de tela, e vou passar no meu checkout, teria como via server side ao menos eu consultar a taxa cadastrada para aquela determinada parcela ?
Estou prevendo uma possivel brecha de meu pagamento parcelado ser alterado em tempo de tela, e minha finalizacao ficar 'aberta' para possiveis mexidas no valor, assim eu faria meu valor 'bruto' x resposta-api-efi-taxas-cartao-mastercard-parcela-3 (no fundo a mesma coisa que simular installments via server side, mas sem o JS e então obter para conferencia o valor que será simulado para pagamento).

-- edit --
Ops...acho que seria essa aqui pelo jeito : /v1/installments , correto ?

Boa tarde! Os pagamentos de assinatura com cartão de crédito (usando POST p/ o endpoint "/plan/:id/subscription/one-step") só estão sendo confirmados/creditados 2 ou 3 dias depois. Até aí tudo bem, foi o acordado em nosso contrato.
Contudo tenho uma dúvida bem básica: as notificações começam a ser enviadas p/ nossa "notification_url" assim que o POST é realizado, com status "waiting" e tal... 3 dias depois, quando o status for "paid" ainda será enviada uma notificação? Não estou conseguindo confirmar a chegada dessa notificação dias depois. É pra chegar, certo?

Olá @lordvitao! No caso de boletos é um pouquinho diferente. A URL deve ser informada em cada requisição; enviaremos um POST com o token de notificação, o seu servidor deve então consultar este token para conseguir visualizar o conteúdo informado.

Qual a url base que você está utilizando no postman ?

Certo, é possivel sim. No PHP você pode utilizar o Curl para realizar as requisições. Segue o exemplo para autenticar na API:

aconteceu algo com a API? a cobrança é feita e registrada mas recebo um cURL error 28 Operation timed out after 30006 milliseconds e a resposta retorna vazia

Bom dia

Estou desenvolvendo a area de pagamento via cartão de crédito de uma loja utilizando o lightbox da gerencianet, porém me deparei com um problema.
ao receber o POST com os dados para efetuar a cobrança na minha url, retorna erro 419 | page expired

acredito que seja por conta da verificação do csrf token que o laravel executa

existe alguma forma de incluir o CSRF token no cabeçalho do POST enviado para a URL? ou esse erro pode ser por algum outro motivo?

estou utilizando o SDK para php.

Olá <@!176140065729282048> ! Boa noite. O fluxo para recebimento das notificações na API de Emissões é um pouco diferente. Basicamente, a Gerencianet fará um POST para a URL cadastrada a cada mudança no status da cobrança. Essa notificação possui um token específico, que será o mesmo durante todo o "ciclo de alterações" da transação. Seu sistema deve então consultar essa notificação através da rota GET /notification/:token, passando o token enviado no POST. Para visualizar os detalhes completos deste fluxo, acesse: https://dev.gerencianet.com.br/docs/notificacoes-recebendo

O POST que enviamos para a URL informada vai conter apenas uma informação: um token de notificação. A partir desse token, você consegue consultar as informações de uma cobrança. Para isso, você precisa consumir a rota GET /notification/:token, em que :token é o token de notificação contido no POST enviado. A resposta será todos os dados informativos sobre a alteração sofrida pela cobrança, como por exemplo, o status anterior e atual da cobrança.

Gere a cobrança de cartão em desenvolvimento que o status vai ser alterado para pago e notificar a url informada. Aqui tem alguns exemplos do JSON que enviamos para cada tipo de cobrança: https://dev.gerencianet.com.br/docs/notificacoes-recebendo#section-2-1-exemplos-de-respostas-

Só não ficou claro pra mim o envio de duas urls de notificação. Só é permitido o envio de uma e se quiser alterar posteriormente você pode consumir a rota PUT metadata