Esse repositório não será mais atualizado.
Novas atualizações da especificação da API do DICT serão publicadas somente no site do Banco Central do Brasil.
API do DICT - Diretório de Identificadores de Contas Transacionais
Esse repositório não será mais atualizado.
Novas atualizações da especificação da API do DICT serão publicadas somente no site do Banco Central do Brasil.
Prezados, boa tarde.
Notamos que existe um erro de ortografia na API do DICT em uma das opções do resultado da análise da devolução, sendo as opções:
A ortografia correta seria "PARTIALLY_ACCEPTED". Poderiam por gentileza confirmar se devemos prosseguir com a escrita refletida na API para o lançamento do dia 16 ou se devemos considerar a ortografia correta?
Na seção 18.5. Fluxo de cancelamento de devolução do Manual Operacional do Dict é detalhado a questão sobre Cancelamento de Devolução.
A dúvida é a respeito do cancelamento de devolução de uma devolução que tenha sido originada a partir de uma falha operacional.
Esse é um cenário possível?
Boa tarde,
percebemos que nossa instituição está fazendo muitas reconciliações ultimamente. Depois de uma investigação, identificamos que as reconciliações são causadas por chaves que passaram por um reivindicação - onde nossa instituição é o reivindicador - e que o dado inconsistente é o de Request ID da chave. O Request ID é o único campo utilizado no cálculo de CID que não acompanha o payload de Reivindicação. Acredito que seja o caso de nós como instituição reivindicadora, ao concluir a reivindicação, podermos informar um RequestID para que possamos, desde já calcular o CID corretamente sem a necessidade de realizar reconciliação para todas as chaves reivindicadas, pois reconciliação envolve custos.
Prezados, bom dia !
Estamos com alguns Infraction Refund abertos e em todo caso de fechamento, seja por TOTALLY_ACCEPTED, PARTIALLY_ACCEPTED ou até mesmo REJECTED recebemos um {"version":"1.0.13","status":400,"errors":[{"message":"The given refund transaction is not a refundable type.","errorCode":"PBE315"}]}
.
Além disso, alguns desses infractions abertos tiveram infraction Reports prévios, ora como FRAUD ora como REFUND_REQUEST, mas em nenhum dos casos conseguimos realizar o fechamento com sucesso.
Podem nos ajudar a entender o motivo e qual encaminhamento tomar?
Lendo a documentação fiquei com a seguinte dúvida: o que aconteceria se duas instituições diferentes quiserem associar suas respectivas contas a uma mesma chave de roteamento (cpf, e-mail, etc)? Na apresentação do Pix foi falado que essa associação seria sempre de um para um para evitar que o comprador precisasse escolher a instituição de pagamento a partir de uma lista.
Prezados, boa tarde.
Recebemos uma transferência que resultou em um bloqueio cautelar e a devolução para o PSP do pagador. Como foi confirmada a suspeita de fraude do cliente recebedor, realizamos abertura de uma infração do tipo "fraude" (infraction-report: 9d122d63-b6e5-485c-bd98-5a4fa976b3a8) como "credited_participant", porém ao tentar "agree" com essa infração, o BC está nos retornando o erro abaixo:
https://dict.pi.rsfn.net.br/api/v1/error/Forbidden
<title>Forbidden</title> 403 Participant is not allowed to access this resourcePoderiam por favor nos orientar se a infração deveria ser aberta de outra forma para possibilitar a abertura e conclusão pelo PSP recebedor neste cenário?
Olá,
Estamos recebendo erro 500 ao tentar criar um relato de infração com o tipo REFUND_CANCELLED informando o EndToEnd da devolução no atributo TransactionId.
<problem xmlns="urn:ietf:rfc:7807">
<type>https://dict.pi.rsfn.net.br/api/v1/error/InternalServerError</type>
<title>Internal Server Error</title>
<status>500</status>
<detail>Internal server error. Please contact support for details.</detail>
<correlationId>B2021110510112495016d5b8f4679feb</correlationId>
</problem>
Vocês podem avaliar?
Hoje só é possível passar a razão social da empresa na criação de um pedido de reivindicação. Para utilizar a razão social temos que concluir a reivindicação e depois alterar o registro para adicionar o nome fantasia.
O ideal seria poder informar no momento da criação do pedido de reivindicação.
olá @luizlaydner e demais pessoas que mantêm o repositório!
percebemos que várias chamadas ao dict em homolog estão recebendo como resposta o status code 503 Service Unavailable
.
gostaria de confirmar se o sistema está passando por manutenção e, se possível, saber se há uma previsão de retorno?
obrigada 🤓
Prezados,
Uma dúvida, quando a nova versão do DICT estará publicada em produção?
Notamos que na versão 1.2.0 da API foi incluída a observação sobre este serviço:
"A atualização de informações de reinvindicações para listagens é assíncrona em relação às operações de inclusão e atualização de registros, sendo assim, é possível haver um retardo de 5 segundos até que os dados incluídos ou alterados constem na consulta."
Estamos deixando de puxar algumas respostas do Doador o que está causando transtornos. Por isto é importante para nós termos os seguintes esclarecimentos.
1) Tempo do delay
É esperado que o delay para que alterações nas reinvindicações sejam refletidas na consulta possa ser na prática maior do que 5 segundos?
2) Valor efetivo do campo LastModified
após uma alteração ser refletida na consulta
Quando o Doador atua sobre a claim alterando seu status, e quando ocorre um delay até a alteração do status ser refletida no serviço "Listar Reivindicações", o valor do campo LastModified
da claim será o timestamp de quando a alteração de status ocorreu originalmente, ou será o timestamp de quando ela passou a constar na consulta?
Exemplo:
01:44:00
=> Doador cancela a claim01:44:05
=> alteração passa a ser refletida na consulta.A partir deste momento, a claim será considerada na consulta com LastModified
igual a 01:44:00
ou igual a 01:44:05
?
3) Alterações em claims serem refletidas fora de ordem
Se a resposta da pergunta anterior for que o LastModified
será sempre a data/hora original da atualização de status, devido ao aspecto assíncrono da atualização de informações, pode ocorrer da atualização da listagem ser feita fora de ordem?
Por exemplo, o seguinte cenário poderia ocorrer?
01:44:00
=> Doador cancela a Claim 1.01:44:02
=> Doador cancela a Claim 2.01:44:03
=> alteração da Claim 2 passa a ser refletida na consulta, com valor de LastModified
igual a 01:44:02
.01:44:05
=> alteração da Claim 1 passa a ser refletida na consulta, com valor de LastModified
igual a 01:44:00
.Obrigado
Solicitamos a geração de arquivos CID. Recebemos o status AVAILABLE para o arquivo abaixo:
https://arq-h.pi.rsfn.net.br/api/v1/download/01181521/cidsetfile/01181521_EMAIL_14241_2020-08-27T17:01:08.273Z.txt
Segue o XML de retorno:
<GetCidSetFileResponse><ds:Signature xmlns:ds="http://www.w3.org/2000/09/xmldsig#"><ds:SignedInfo><ds:CanonicalizationMethod Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/><ds:SignatureMethod Algorithm="http://www.w3.org/2001/04/xmldsig-more#rsa-sha256"/><ds:Reference URI="#key-info-id"><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><ds:DigestValue>pHDbsKklpORCx1ABvvlCOZIg/+2QjO90lesGqdGitbE=</ds:DigestValue></ds:Reference><ds:Reference URI=""><ds:Transforms><ds:Transform Algorithm="http://www.w3.org/2000/09/xmldsig#enveloped-signature"/><ds:Transform Algorithm="http://www.w3.org/2001/10/xml-exc-c14n#"/></ds:Transforms><ds:DigestMethod Algorithm="http://www.w3.org/2001/04/xmlenc#sha256"/><ds:DigestValue>Fknk1JyQD/Pz0l7Mw5DDk7NtOUolq1VF4i9yDHQQ4O4=</ds:DigestValue></ds:Reference></ds:SignedInfo><ds:SignatureValue>k8c/w0vI8O8Kufy0QUeD7DJywfIyrGKuPwI/m2AUpFThZQssZWCX0scZazqC92zrXiBwSJOS6zEl
rZ+Z7/Al8+lqKgFCQ0n2RDu9L6J4wHDD0YMGtsHJSJZhXLiyOg2gCi70Lc+OUVKe5LgSwSjqIdgf
YTuIQH0ksQBcugzKInFyr4NvH4LW1EyPzlIDcpBBZyKI8dUvb98VCiEKD2fFKaMaAQnj4dukylBS
Hxubpi2nEmDNLG+BxHb9GjOVX4kBX+W7Gml4360hZtH+yC8CWpp20JXjLsCQMJYjrceBNjDAIbla
epcBKslV2YMGeuDzCXOSXsjbADNzg0JEmm0QEQ==</ds:SignatureValue><ds:KeyInfo Id="key-info-id"><ds:X509Data><ds:X509IssuerSerial><ds:X509IssuerName>CN=Autoridade Certificadora do SERPRO Final SSL, OU=Servico Federal de Processamento de Dados - SERPRO, OU=CSPB-1, O=ICP-Brasil, C=BR</ds:X509IssuerName><ds:X509SerialNumber>66906355272994040667436154809</ds:X509SerialNumber></ds:X509IssuerSerial></ds:X509Data></ds:KeyInfo></ds:Signature><CidSetFile><Id>14241</Id><Status>AVAILABLE</Status><Participant>01181521</Participant><KeyType>EMAIL</KeyType><RequestTime>2020-08-27T17:01:08.256Z</RequestTime><CreationTime>2020-08-27T17:01:08.734Z</CreationTime><Url>https://arq-h.pi.rsfn.net.br/api/v1/download/01181521/cidsetfile/01181521_EMAIL_14241_2020-08-27T17:01:08.273Z.txt</Url><Bytes>12090</Bytes><Sha256>9748064e9f7d47d54f4ae4a0fcf2d519c686204a056d5b60303c274d1bba0f06</Sha256></CidSetFile></GetCidSetFileResponse>
Segue o retorno para o GET da URL:
<?xml version="1.0" encoding="UTF-8"?>
<problem xmlns="urn:ietf:rfc:7807">
<type>https://icom.pi.rsfn.net.br/api/v1/error/notFound</type>
<title>Não encontrado</title>
</problem>
Estávamos comunicando com sucesso com os serviços do DICT e SPI, porém começamos a receber a rejeição abaixo quando acessamos (https://dict-h.pi.rsfn.net.br/api/v1/entries/00038166000105)
https://dict.pi.rsfn.net.br/api/v1/error/BadRequest
<title>Bad Request</title> 400 Version not available. Available versions: [v1-rc4, v1-rc5]Comunicação com SPI funcionando com sucesso, apenas o DICT apresentou essa rejeição.
Alguém mais passou por isso ?
Prezados, boa tarde.
Conforme consulta realizada ao marcado com prazo de resposta de 15/10, foi indicado que o endpoint de estatísticas do DICT retornaria 24 informações, sendo elas:
· Qtd de liquidações por CPF/CNPJ nos últimos 3 dias
· Qtd de liquidações por CPF/CNPJ nos últimos 30 dias
· Qtd de liquidações por CPF/CNPJ nos últimos 6 meses
· Qtd de liquidações por conta nos últimos 3 dias
· Qtd de liquidações por conta nos últimos 30 dias
· Qtd de liquidações por conta nos últimos 6 meses
· Qtd de relatos de infração abertos por CPF/CNPJ nos últimos 3 dias (inclui os relatos do tipo SPI e INTERNAL)
· Qtd de relatos de infração abertos por CPF/CNPJ nos últimos 30 dias (inclui os relatos do tipo SPI e INTERNAL)
· Qtd de relatos de infração abertos por CPF/CNPJ nos últimos 6 meses (inclui os relatos do tipo SPI e INTERNAL)
· Qtd de relatos de infração abertos por conta nos últimos 3 dias (inclui os relatos do tipo SPI e INTERNAL)
· Qtd de relatos de infração abertos por conta nos últimos 30 dias (inclui os relatos do tipo SPI e INTERNAL)
· Qtd de relatos de infração abertos por conta nos últimos 6 meses (inclui os relatos do tipo SPI e INTERNAL)
· Qtd de relatos de infração confirmados por CPF/CNPJ nos últimos 3 dias (inclui os relatos do tipo SPI e INTERNAL)
· Qtd de relatos de infração confirmados por CPF/CNPJ nos últimos 30 dias (inclui os relatos do tipo SPI e INTERNAL)
· Qtd de relatos de infração confirmados por CPF/CNPJ nos últimos 6 meses (inclui os relatos do tipo SPI e INTERNAL)
· Qtd de relatos de infração confirmados por conta nos últimos 3 dias (inclui os relatos do tipo SPI e INTERNAL)
· Qtd de relatos de infração confirmados por conta nos últimos 30 dias (inclui os relatos do tipo SPI e INTERNAL)
· Qtd de relatos de infração confirmados por conta nos últimos 6 meses (inclui os relatos do tipo SPI e INTERNAL)
· Qtd de relatos de infração do tipo REJECTED_PAYER e REJECTED_PAYEE abertos e confirmados por CPF/CNPJ nos últimos 3 dias
· Qtd de relatos de infração do tipo REJECTED_PAYER e REJECTED_PAYEE abertos e confirmados por CPF/CNPJ nos últimos 30 dias
· Qtd de relatos de infração do tipo REJECTED_PAYER e REJECTED_PAYEE abertos e confirmados por CPF/CNPJ nos últimos 6 meses
· Qtd de relatos de infração do tipo REJECTED_PAYER e REJECTED_PAYEE abertos e confirmados por conta nos últimos 3 dias
· Qtd de relatos de infração do tipo REJECTED_PAYER e REJECTED_PAYEE abertos e confirmados por conta nos últimos 30 dias
· Qtd de relatos de infração do tipo REJECTED_PAYER e REJECTED_PAYEE abertos e confirmados por conta nos últimos 6 meses
Porém a API DICT versão 1.7.0 apenas retorna 9 campos de informações. Gostaríamos de confirmar que o que consta na API é o schema final que deve ser considerando para a data de implementação do bloqueio cautelar de 16/Nov.
Boa tarde, pessoal!
Vocês possuem algum link do swagger dessa nova versão do DICT? Antes eu pegava o openapi.yaml e colava num serviço para transformar numa documentação. Mas agora como a referência de responses e schemas estão fora do openapi.yaml, não está dando mais para fazer isso. Poderiam me ajudar com isso?
Atenciosamente,
Tawan Abreu.
Good afternoon,
It was missing the specification of the parameter Id the endpoint.
pix-dict-api/openapi/openapi.yaml
Line 1058 in e2e3aa8
Segundo o Manual Operacional do Dict na seção 17. Cache de existência de chave Pix:
O cache de existência de chave Pix pode ser alimentado a partir das seguintes fontes:
d. verificação de chaves registradas no DICT (checkKeys).
Caso o registro no cache seja feito por meio da fonte “d”, o registro deve seguir as diretivas contidas no header Cache-Control, para que ele seja válido.
Porém ao chamar o endpoint /keys/check não está sendo retornado o atributo max-age no header cache-control.
Testando no PostMan, o endereço da doc dict api, não existe.
No caso testei a consulta publica pra keys na rede.
Documentação consultada:
https://www.bcb.gov.br/content/estabilidadefinanceira/pix/API-DICT.html#tag/Key
Olá, após criar um novo Vínculo e tentar consultá-la recebo um erro informando que não posso consultar vínculos que estão sobe minha custódia. Vocês possuem uma massa de dados de teste para consultas de vínculos?
Olá, sobre as devoluções
Alguns campos perdem o prefixo Refund dentro das respostas (como RefundTransactionId que nas respostas se torna apenas TransactionId), porém alguns campos continuam com Refund mesmo na resposta (como RefundReason), isto está correto ou foi um erro ao criar os XML's de exemplo?
O campo RefundRejectionReason não aparece em nenhum exemplo de resposta em XML, dentro da resposta ainda será RefundRejectionReason ou será apenas RejectionReason?
<?php
namespace App\sts\Controllers;
if (!defined('URL')) {
header("Location: /");
exit();
}
class Reconciliacao
{
private $Dados;
function stringGuidAsBinaryGuid($stringGuid)
{
$binary = pack("H*", str_replace('-', '', $stringGuid));
return $binary;
}
function binaryGuidAsStringGuid($binaryGuid)
{
$string = unpack("H*", $binaryGuid);
$string = preg_replace(
"/([0-9a-f]{8})([0-9a-f]{4})([0-9a-f]{4})([0-9a-f]{4})([0-9a-f]{12})/",
"$1-$2-$3-$4-$5",
$string["1"]
);
return $string;
}
public function calc()
{
//Dados necessários para pegar o montar o CID
$type = "EMAIL";
$email = "[email protected]";
$ownerTaxIdNumber = "51857504488";
$ownerName = "Andreia Oliveira Almeida";
$ownerTradeName = "";
$participant = "yourNumber";
$branch = "0002";
$accountNumber = "170888053967579";
$accountType = "CACC";
$entryAttributes = "$type&$email&$ownerTaxIdNumber&$ownerName&$ownerTradeName&$participant&$branch&$accountNumber&$accountType";
$requestIdBytes = "670032e7-e4b6-4f60-8a30-bdcd30ca971f";
$bin = $this->stringGuidAsBinaryGuid($requestIdBytes);
$cidBytes = hash_hmac('sha256', $entryAttributes, $bin, false );
// variavel cidBytes contém o resultado do cid;
// o exemplo abaixo mostra como montar o calculo de cid`s com bitwise em Xor os cid's abaixo temos
// exemplos de cid's forncecidos na doc documentação do banco central onde o objetivo foi chegar no resultado do exemplo da doc
// https://gokeitecnologia.com.br/api-docs/SPI/DICT/#section/Calculo-de-CID
// na documentação o resultado esperado tem que ser igual a 996fc1dd3b6b14bcf0c9fe8320eb66d7e2a3fd874ccf767b2e939641b1ea8eaf
$cidP1 = $this->stringGuidAsBinaryGuid('28c06eb41c4dc9c3ae114831efcac7446c8747777fca8b145ecd31ff8480ae88');
$cidP2 = $this->stringGuidAsBinaryGuid('4d4abb9168114e349672b934d16ed201a919cb49e28b7f66a240e62c92ee007f');
$cidP3 = $this->stringGuidAsBinaryGuid('fce514f84f37934bc8aa0f861e4f7392273d71b9d18e8209d21e4192a7842058');
$x = $cidP1 ^ $cidP2 ^ $cidP3;
echo str_replace("-", "", $this->binaryGuidAsStringGuid($x));
}
}
Caros a título de informação documentação em formato Swagger - Unofficial API Swagger
Fizemos uma chamada para criação de um Relato de Infração e recebemos um Problem com um type não previsto na documentação
type retornado: https://dict.pi.rsfn.net.br/api/v1/error/InfractionReportTransactionNotSettled
Este type não está na documentação disponibilizada em https://github.com/bacen/pix-dict-api/blob/master/openapi/openapi.yaml e com isso não estamos conseguindo fazer os devidos tratamentos.
olá!
no ambiente de homolog, estamos recebendo status code 500 no endpoint "Criar Relato de Infração"
o problem que vem na response:
https://dict.pi.rsfn.net.br/api/v1/error/InternalServerError
Internal Server Error
500
Internal server error. Please contact support for details.
conseguem nos informar uma estimativa de retorno?
Motivação
Existem participantes diretos que oferecem acesso a um grande número de participantes indiretos. Algumas operações de polling da API do DICT, tais como listClaims e listInfractionReports, são feitas hoje para apenas um participante individual. A implicação disso é que esses participantes com muitos indiretos vinculados precisam fazer um grande número de chamadas à API, o que é ineficiente do ponto de vista de uso de recursos do sistema.
Propostas
Alternativa 1: Adicionar um parâmetro booleano opcional includeIndirectParticipants nas operações de listClaims e listInfractionReports, que quando true incluiria adicionalmente os claims/infractionReports de todos os indiretos vinculados ao participante direto que está solicitando.
Alternativa 2: Adicionar um parâmetro array indirectParticipant que permitiria passar uma lista de participantes indiretos vinculados ao direto para os quais se deseja listar claims/infractionReports.
Perguntas:
Olá pessoal,
Teriam Contas ou Chave de Endereçamento em ambiente de homologação com o tipo de conta TRAN para teste
Prezados,
Estamos recebendo no GetEntryResponse do ambiente não produtivo o atributo "type" das estatísticas com um tipo que não consta nas documentações da API do Dict.
Abaixo exemplo do XML recebido com o tipo "REJECTED".
<GetEntryResponse> <CorrelationId>B202111160943372a2cc27f3bac86f0a</CorrelationId> <ResponseTime>2021-11-16T12:43:37.614Z</ResponseTime> <Entry> <Key>[email protected]</Key> <KeyType>EMAIL</KeyType> <Account> <Participant>60701190</Participant> <Branch>1500</Branch> <AccountNumber>00589328</AccountNumber> <AccountType>CACC</AccountType> <OpeningDate>2019-03-17T03:00:00Z</OpeningDate> </Account> <Owner> <Type>NATURAL_PERSON</Type> <TaxIdNumber>38402631827</TaxIdNumber> <Name>PMD Rafa Biiir</Name> </Owner> <CreationDate>2021-11-14T14:30:11.299Z</CreationDate> <KeyOwnershipDate>2021-11-14T14:30:11.298Z</KeyOwnershipDate> </Entry> <Statistics> <LastUpdated>2021-11-15T19:18:31.335Z</LastUpdated> <Counters> <Counter by=\"KEY\" d3=\"11\" d30=\"11\" m6=\"11\" type=\"SETTLEMENTS\"/> <Counter by=\"OWNER\" d3=\"11\" d30=\"36\" m6=\"36\" type=\"SETTLEMENTS\"/> <Counter by=\"ACCOUNT\" d3=\"11\" d30=\"36\" m6=\"36\" type=\"SETTLEMENTS\"/> <Counter by=\"KEY\" d3=\"1\" d30=\"1\" m6=\"1\" type=\"REPORTED_FRAUDS\"/> <Counter by=\"OWNER\" d3=\"1\" d30=\"3\" m6=\"2\" type=\"REPORTED_FRAUDS\"/> <Counter by=\"ACCOUNT\" d3=\"1\" d30=\"3\" m6=\"2\" type=\"REPORTED_FRAUDS\"/> <Counter by=\"KEY\" d3=\"0\" d30=\"0\" m6=\"0\" type=\"CONFIRMED_FRAUDS\"/> <Counter by=\"OWNER\" d3=\"0\" d30=\"0\" m6=\"0\" type=\"CONFIRMED_FRAUDS\"/> <Counter by=\"ACCOUNT\" d3=\"0\" d30=\"0\" m6=\"0\" type=\"CONFIRMED_FRAUDS\"/> **<Counter by=\"KEY\" d3=\"0\" d30=\"0\" m6=\"0\" type=\"REJECTED\"/> <Counter by=\"OWNER\" d3=\"0\" d30=\"0\" m6=\"0\" type=\"REJECTED\"/> <Counter by=\"ACCOUNT\" d3=\"0\" d30=\"0\" m6=\"0\" type=\"REJECTED\"/>** </Counters> </Statistics> </GetEntryResponse>
Prezados,
Na versão 1.2.0 da API do DICT, é permitido alterar os dados do "Owner" na funcionalidade de Atualizar Vínculo. Porém ao tentar realizar a alteração de uma chave aleatória, só é permitido com a razão "BRANCH_TRANSFER". Não achei em nenhum lugar o motivo para tal regra. Existe alguma documentação para que possa ler e entender melhor a respeito disso?
Não poderia ser usada a razão "USER_REQUESTED" ou "RECONCILIATION", conforme documentado na API?
Quanto tempo a chamada de consulta de chave no DICT deve entrar em timeout em caso de ausência de resposta?
Prezados, boa tarde.
Revisando a documentação da API DICT, identificamos que o campo refundtransactionid não é de preenchimento obrigatório ("required") ao fechar uma solicitação de devolução no MED. Em testes realizados em homologação, alguns PSPs estão enviando esse campo em branco ao concluir uma devolução.
Gostaríamos de sugerir de alterar este campo para "required" de forma condicional: quando for encerramento de um devolução em que houve a refund-transaction, esse campo deve ser obrigatório.
Isso ajuda a ter mais confiança no mecanismo, possibilitando que possamos fazer conciliação entre a solicitação de refund e o refund efetivamente criado.
Descreva sua dúvida ou problema
Ao realizar a request para salvar uma Claim está sendo retornado "Bacen Message - Internal server error. Please contact support for details."
Sistema ou Área
DICT
Identificador do Problema
<type>https://dict.pi.rsfn.net.br/api/v1/error/InternalServerError</type>
<title>Internal Server Error</title>
<status>500</status>
<detail>Internal server error. Please contact support for details.</detail>
<correlationId>B202104261132190943965fab2d65a52</correlationId></problem>
Hora: em torno de 11:00h
Mensagens Enviadas / Recebidas
Requisição:
POST https://dict-h.pi.rsfn.net.br:16522/api/v1/claims
POST data:
{
"claimerAccount":{
"accountNumber":"462186",
"accountType":"CACC",
"branch":"5820",
"participant":"99999012"
},
"key":"+5511471916107",
"keyType":"PHONE",
"type": "OWNERSHIP",
"claimer":{
"name":"Teste BV",
"taxIdNumber":"98574764137",
"type":"NATURAL_PERSON"
}
}
[no cookies]
Resposta:
{
"code": "3007",
"origin": "BACEN",
"messages": [
"Bacen Message - Internal server error. Please contact support for details."
],
"timestamp": "2021-04-26 02:32:19"
}
URL de conexão
https://dict-h.pi.rsfn.net.br:16522/api
olá!
ao tentar consultar, listar e agir sobre entries, claims e infraction reports em ambiente homolog estamos recebendo apenas respostas 404 Not Found
(ou listas fazias)
gostaria de saber: os dados em homolog foram zerados?
obrigada.
Pessoal, bom dia.
De acordo com o Manual Operacional do DICT, existem três motivos para rejeição de pedidos de devolução que podem ser utilizados, sendo eles:
Temos dúvidas com relação a qual motivo de rejeição utilizar nos seguintes cenários:
Poderiam por favor nos auxiliar?
Ao realizar a consulta no Dict é retornado o valor 0001-01-01T00:00:00Z na tag OpeningDate para algumas chaves.
Esse valor pode ser entendido como uma openingDate vazia|nula ?
Existe algum valor mínimo para esse campo?
Boa tarde, verifiquei que foi disponibilzado o openapi.yaml de como será a API do DICT que o BACEN irá prover. Achei bem legal a iniciativa, entretanto ao subir em um container do swagger-ui verifiquei que alguns arquivos não estão disponíveis para o import via $ref. O caminho inicial de alguns arquivos que faltam são:
Segue abaixo o repositório com a configuração via docker-composer para subir o container com swagger-ui
https://github.com/lift-learning/pix-api
Motivação: Os filtros isDonor, isClaimer da operação de listClaims não tem comportamento muito claro para algumas combinações de valores. Além disso, a especificação não deixa bem definido se esses filtros se combinam como conjunção (AND) ou como disjunção (OR). Por fim, há ainda que se considerar o comportamento quando o valor de um desses parâmetros não é passado.
Essa complexidade toda deixa a API menos intuitiva e mais propensa a erros de implementação.
Proposta: Adicionar um parâmetro role, que poderia assumir os valores DONOR ou CLAIMER, na filtragem de listClaims.
Para manter a compatibilidade da API, os parâmetros isDonor e isClaimer continuariam a existir e teriam sua definição com base em uma equivalência ao parâmetro role. Algumas combinações "estranhas" (não utilizadas na prática) passariam a ser inválidas.
A tabela abaixo resume o comportamento atual da API e o comportamento com a nova definição.
isDonor | IsClaimer | Comportamento atual | Nova definição em termos de "role" |
---|---|---|---|
True | True | Retorna claims em que participante é doador OU reivindicador | Inválido |
True | Retorna claims em que participante é doador | role=DONOR | |
True | False | Retorna claims em que participante é doador | role=DONOR |
False | True | Retorna claims em que participante é reivindicador | role=CLAIMER |
False | Retorna claims em que participante é reivindicador | role=CLAIMER | |
False | False | Retorna claims em que participante é doador OU reivindicador | Inválido! |
True | Retorna claims em que participante é reivindicador | role=CLAIMER | |
False | Retorna claims em que participante é reivindicador (bug!) | role=DONOR | |
Retorna claims em que participante é doador OU reivindicador | role= |
Perguntas:
Proposta complementar: Tornar o parâmetro role obrigatório.
A fim de simplificar o desenho do backend do DICT, melhorar o desempenho da query e diminuir o consumo de recursos no SGBD, estamos considerando a alternativa de tornar o parâmetro role obrigatório.
Perguntas:
Tornar esse parâmetro obrigatório teria impacto de implementação muito grande no seu participante ?
Fala pessoal, tranquiilo? Desde ontem +- 14h, passamos a receber erros de conexão ao realizar requests para o DICT em HML. Ainda estamos investigando do nosso lado, mas queríamos descartar uma possível instabilidade do DICT.
Podem confirmar se está tudo funcionando normalmente?
Bom dia,
Estamos fazendo o sincronismo baseado no arquivo CID, mas o download tem demorado com o crescimento da base de dados.
Fazemos algumas checagens com o log de eventos mas em determinadas situações, ainda se faz necessário o download do arquivo.
Atualmente este arquivo fica disponível no formato texto aberto. Existe alguma forma de solicitar o download do arquivo compactado ? Se hão houver esta possibilidade, entendo que seria uma melhoria muito importante, já que a taxa de compressão em texto costuma ser alta.
Obrigado!
Olá!! No serviço para abrir um pedido de portabilidade/reivindicação, pode ser retornado o status de erro 404?
Pelo Redoc, os erros mapeados são os abaixo.
Mas estamos recebendo um response com o erro 404.
<ds:X509SerialNumber>66906355272994040667436154809</ds:X509SerialNumber></ds:X509IssuerSerial></ds:X509Data></ds:KeyInfo></ds:Signature><type>https://dict.pi.rsfn.net.br/api/v1/error/ClaimKeyNotFound</type><title>Not Found</title><status>404</status><detail>Entry associated with given key does not exist</detail><correlationId>f9d73c535297bc3a1d720d797e6fc10c</correlationId></problem>
Quando um PSP tenta cadastrar uma claim chamando o serviço "Criar Reivindicação", o PSP está sujeito a passar por um cenário onde o PSP sofre um crash após obter a response do serviço (ou após iniciar a request para o serviço) e antes de salvar no seu ambiente os dados da claim criada.
Já passamos por este problema algumas poucas vezes o que causou transtorno.
Hoje, não há forma efetiva do PSP lidar com esta questão. O PSP pode, antes de fazer a requisição, salvar em seu ambiente a intenção de criar a claim, de forma que se o crash ocorrer, ele pode ter um processo de recuperação ou de retry. Só que, se o PSP tenta cadastrar a claim novamente, ele recebe o erro ClaimAlreadyExistsForKey
. Ao ocorrer isso, o PSP até pode assumir que esta claim que já existe é a claim que ele está tentando criar. Mas isto não é muito seguro. O mais correto seria, ao receber este erro, o PSP ter como consultar os dados desta claim no lado do DICT, para confirmar que trata-se mesmo da claim que ele queria registrar. Só que o PSP neste ponto, não tem em mãos o ID da claim para consultar por ele (visto que na primeira tentativa houve o crash). E utilizar o serviço "Listar Reivindicações" para tentar encontrar a claim não é efetivo.
O melhor seria que a API tivesse uma destas duas alterações/melhorias:
ClaimAlreadyExistsForKey
, retornar também o ID da claim.ou
A primeira alteração seria mais direta e mais voltada para este problema em específico. A segunda alteração (incluir filtro da chave no serviço "Listar Reinvindicações") poderia ajudar a resolver outros tipos de situações também.
Olá,
Estamos recebendo em homolog o status code 500 no endpoint de "Criar Relato de Infração" e "Criar uma Solicitação de Devolução", ambos com o seguinte problem:
https://dict.pi.rsfn.net.br/api/v1/error/InternalServerError
Internal Server Error
500
Internal server error. Please contact support for details.
Há estimativa de retorno ao funcionamento normal?
olá! preciso de um apoio para a operação "Fechar solicitação de devolução".
no ambiente de homolog, estamos tentando fazer uma requisição no endpoint /api/v1/refunds/{RefundId}/close
no DICT, passando as seguintes informações:
RefundId = <refund_id>
Participant = <participant>
RefundAnalysisResult = "REJECTED"
RefundAnalysisDetails = "detalhes da análise #01"
RefundRejectionReason = "NO_BALANCE"
RefundTransactionId = vazio
como resposta, estamos recebendo o seguinte problem:
Type: https://dict.pi.rsfn.net.br/api/v1/error/BadRequest
Title: Bad Request
Status: 400
Detail: Invalid parameters
Violation:[ {
Reason: must match \"^\\w{32}$\"
Value: ""
Property: refundTransactionId
}]
de acordo com o manual, considerando que o Result é "REJECTED", não deveria ser necessário passar um "RefundTransactionId", afinal não há transação de devolução - e por isso estamos passando o campo vazio.
conseguem nos ajudar a entender onde estaria o problema? estamos tentando fechar a solicitação de devolução de ID d93cd706-af4d-465e-8e8f-cf571e6ccff0
Atualmente, é possível filtrar as infrações em que o PSP é o debitado e/ou creditado, independente se ele foi o criador ou não da infração, e isso, em alguns casos,, retorna muitos registros desnecessários. Há momentos em que é importante saber, por exemplo, apenas as infrações que foram criadas pelo PSP debitado.
A sugestão do filtro "reportedBy" poderia otimizar a pesquisa, já que o PSP criador da infração pode ser, ora o debitado ora o creditado.
Recebemos notícia de um cliente sobre a recente publicação de uma atualização da especificação DICT versão 1.6.1.
O cliente nos informou o seguinte URL para a especificação atualizada:
https://www.bcb.gov.br/content/estabilidadefinanceira/pix/API-DICT-1-6-1.html
Este repositório deixou de ser referência normativa para a especificação DICT?
A primeira coisa é sobre o tipo "RefundAnalysisResult", um dos possíveis valores é "PARCIALlY_ACCEPTED". Acredito que a grafia correta seria "PARTIALLY_ACCEPTED".
A segunda coisa é: A solicitação de devolução já está funcional em homologação?
1- Observei que os arquivos .json e YAML parecem estar desatualizados não contendo as informações da consulta de existência de chaves (CheckKeys).
2- Seria possível forcener a sintaxe e regra de composição deo campo Cache_control do header?
Não localizei regras desse campo no swagger ou no documento "Manual Operacional do Diretório de Identificadores de Contas Transacionais (DICT)".
Bom dia,
De acordo com a API, quando vamos consular os arquivos de CIDs, em reconciliação, existem cinco status para o objeto: CidSetFile:
Gostaria de saber se esta documentando quais são os status transitórios e quais são os status finais. Casso não esteja teria como documentar na API ou no manual operacional do DICT e me auxiliar nessa dúvida?
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.