bacen/pix-dict-api

API do DICT - Diretório de Identificadores de Contas Transacionais

OBSOLETO

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.

pix-dict-api's Issues

Serviço para abrir pedido de portabilidade/reivindicação retorna erro 404

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>  

Dúvidas Mecanismo Especial de Devolução - Refund rejection reason

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:

• no_balance : falta de saldo na conta do cliente
• account_closure : relacionamento com cliente encerrado
• cannot_refund : participante não pode acionar Mecanismo Especial de Devolução

Temos dúvidas com relação a qual motivo de rejeição utilizar nos seguintes cenários:

1. Conta do cliente bloqueada (não podemos retirar o dinheiro da conta para fazer a devolução, ex: bacenjud ou bloqueio cautelar em andamento)
2. Devolução já foi feita manualmente pelo cliente
3. Instabilidade no Pix
4. Pedido de devolução inválido (ex: duplicado, transação +90 dias, pedido tipo fraude sem infração aprovada, etc)

Poderiam por favor nos auxiliar?

GetEntryResponse com domínio (type) de estatística inválido

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>

Existência de um link para o swagger

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.

Permitir mais robustez no cadastro de claims

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:

• ao retornar ClaimAlreadyExistsForKey, retornar também o ID da claim.

ou

• o serviço "Listar Reivindicações" passar a ter uma opção de filtro sobre o valor da chave.

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.

Instabilidade em homologação

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?

cc @erikacarvalho

Associação de chave de roteamento por IPs

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.

Revisar documentação contendo Erros

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.

DICT versão 1.6.1

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?

Erro 500 na Criação de Relatos de Infração com o tipo REFUND_CANCELLED

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?

O campo RefundRejectionReason continuará com o prefixo Refund nas respostas?

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?

Criação de Relatos de Infração retornando 500 em homolog

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?

[Dúvida] Lançamento da api 1.2

Esclarecimentos sobre o serviço "Listar Reivindicações"

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:

1. 01:44:00 => Doador cancela a claim
2. delay
3. 01: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?

1. 01:44:00 => Doador cancela a Claim 1.
2. 01:44:02 => Doador cancela a Claim 2.
3. delay
4. 01:44:03 => alteração da Claim 2 passa a ser refletida na consulta, com valor de LastModified igual a 01:44:02.
5. 01:44:05 => alteração da Claim 1 passa a ser refletida na consulta, com valor de LastModified igual a 01:44:00.

Obrigado

Massa de dados para testes

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?

Geração de Arquivo CID com status AVAILABLE mas ao tentar fazer download do arquivo, retorna 404.

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>

[DICT] Impossibilidade de salvar um claim

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":"[phone]",
   "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

Parameter Id

Good afternoon,

It was missing the specification of the parameter Id the endpoint.

pix-dict-api/openapi/openapi.yaml

Line 1058 in e2e3aa8

'/cids/files/{Id}':

[Dúvida] Geração do Arquivo - Status

Bom dia,
De acordo com a API, quando vamos consular os arquivos de CIDs, em reconciliação, existem cinco status para o objeto: CidSetFile:

• Requested
• Processing
• Available
• Unavailable
• Error

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?

Reivindicação e RequestId

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.

Arquivos referenciados não disponíveis no repositório

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:

• #/components/schemas
• #/components/responses

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

[info] - Swagger - Unofficial API Swagger

Caros a título de informação documentação em formato Swagger - Unofficial API Swagger

https://github.com/entria/awesome-pix#pix-api

[Homolog][Dados] os dados do ambiente de homologação foram zerados?

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.

Not refundable type Pix Refund

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?

API com endereço que não existe

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

[Dúvida][v-1.2.0] - Funcionalidade: Atualizar Vínculo - Possível BUG

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?

Falta do header cache-control/max-age no CheckKeys

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.

Suporte para nome fantasia (tradeName) na criação de reivindicação

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.

Massa de Teste Tipo de Conta TRAN

Olá pessoal,

Teriam Contas ou Chave de Endereçamento em ambiente de homologação com o tipo de conta TRAN para teste

Versão 1.2.0 - Cache_control

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)".

[PROPOSTA] Adição de parâmetro "ReportedBy" para filtragem na operação de listInfractions

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.

API DICT > Refund > AnalysisResult

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:

• "REJECTED"
• "TOTALLY_ACCEPTED"
• "PARCIALlY_ACCEPTED"

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?

[Dúvida] Nova API do DICT - 1.1.0

Prezados,

Uma dúvida, quando a nova versão do DICT estará publicada em produção?

Response Endpoint API DICT - Estatísticas

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.

Infração referente bloqueio cautelar

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 resource

Poderiam 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?

[Dúvida][Manutenção] o dict está em manutenção em homolog?

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 🤓

Sobre devolução

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?

Version not available. Available versions: [v1-rc4, v1-rc5]

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 ?

[PROPOSTA] Adição de parâmetro para facilitar polling de participantes indiretos

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:

• Tal funcionalidade é desejável para o seu participante ?
• Entre as alternativas apresentadas, alguma é preferível ?

Cancelamento de Devolução em caso de FALHA OPERACIONAL

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?

Cálculo Cids em PHP funcionando

<?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));
 
  }
}

[PROPOSTA] Adição de parâmetro role para filtragem na operação de listClaims

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:

• Essa evolução da API a deixaria mais intuitiva ?
• Uma futura remoção dos parâmetros isDonor e isClaimer, com a substituição pelo parâmetro role, teria impacto muito grande de implementação no seu participante?

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 ?

[Homolog] Recebendo Bad Request na operação "Fechar solicitação de devolução"

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

[Dúvida] Download do Arquivo CID com compactação

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!

Devolução - campo refundtransactionid

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.

Criação de Refunds e Criação de Infractions retornando 500 em homolog

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?

[Dúvida] Timeout de consulta de chave

Quanto tempo a chamada de consulta de chave no DICT deve entrar em timeout em caso de ausência de resposta?

[Dúvida] Mínimo valor OpeningDate

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?