lighthouse.dock.tech

Dock Lighthouse

Welcome to Dock Lighthouse! You'll find comprehensive guides and documentation to help you start working with our products as quickly as possible, as well as support if you get stuck. Let's jump right in!

Get Started

DICT Key Experience

The experience of having a DICT Key can be represented by 4 (four) groups:

  • Key Validation;
  • Key Creation;
  • Key Update or Key Claim;
  • Key Claim Confirmation.

Key Validation


The key validation process is recommended to use along with Pix experience. The following entities are part of it:

  • User;
  • DOCK PartnerDOCK Partner - Any and every entity that has a contract to use directly the services offered by DOCK is considered a DOCK Partner.s;
  • DOCK Bank Partner (Pix Direct Partner);
  • DOCK;
  • Central Bank of Brazil (BACEN).

The flowchart below presents the complete experience of key validation in detail.

🚧

Image Quality

If you have difficulty accessing the flowchart below, click here to access the image in a higher resolution.

Key Validation flowchart.

Flowchart Captions

Step

Description

1

User request key validation

2

The user enters the data of a Dict key, which will be validated in DICT (BACEN's API) and replied with the information of the key if it exists

3

The DOCK Partners sends a request to DOCK via API call

4

DOCK receives the request from Partner

5

DOCK checks if the key is registered in its internal database

6

If the key is registered in its internal database, DOCK creates a reply message, which goes straight to step 13

7

If the key is not registered in its internal database, DOCK sends a message to DICT

8

DICT receives the message with a request

9

DICT checks if the key is registered

10

If the key is not registered, DICT creates a message informing that the consulted key does not exist

11

If the key is registered, DICT creates a reply message, which must contain all the data linked to the key

12

DICT sends a reply message to the Pix Direct Partner

13/14

DOCK receives a message with the answer to the request and transmits it to the Partner

15/16

The DOCK Partner receives the message and transmits it to the end-user

17

The user receives a reply message

Key Creation


The key creation process is responsible for the association of a DICT key to an instant payments account. The following entities are part of it:

  • User;
  • DOCK Partners;
  • DOCK Indirect Partner (Pix Direct Partner);
  • DOCK;
  • Central Bank of Brazil (BACEN).

The flowchart below presents the complete experience of key creation in detail.

🚧

Image Quality

If you have difficulty accessing the flowchart below, click here to access the image in a higher resolution.

Key Creation flowchart.

Flowchart Captions

Step

Description

1

The end-user accesses the service channel

2

End-user informs which key he/she wants to register among the five possible types: CPF, CNPJ, e-mail, cell phone number and EVP. End user requests registration of the key

3

DOCK Partner forwards request and necessary data, via API, to DOCK with the key validation request

4

DOCK receives key validation request from the partner

5

DOCK performs key ownership validation via DICT Key Validation process

6/7/8

Message sending and receiving flow between DOCK and Partner for key confirmation

9

The user confirms the creation of a new DICT key

10

DOCK Partner sends communication for key creation

11

DOCK receives communication for key creation

12

Request for key registration is forwarded to DICT

13

DICT receives message with the key registration request

14

DICT performs compliance checks. In the case of EVP, DICT generates the hexadecimal number that will serve as the address

15

If the requested key is not registered in DICT, it is registered by linking the key to the transactional account data

16

If the requested key is already registered in DICT, a message is created indicating the existence of a registration for that key, with the data of the existing key

17

DICT sends a reply message informing the success of the registration or the existence of an already registered key

18/19/20/21

Message transmission process between the members

22

Request for viewing the registered DICT keys. Paying user enters the data, which may correspond to any of the five existing types of keys, of the receiving user

23

DOCK Partner sends a request to DOCK, via API

24

DOCK receives the request from PSP

25

DOCK list DICT Key information

26

DOCK sends a message to DOCK Partner with Keys

27

DOCK Partner receives the message with Keys

Key Update or Key Claim


The key update process has a main behavior, however, it is composed of two different paths:

  • Change an existing key to a new one;
  • Claim existing keys from other users.

The following entities are part of this process:

  • User;
  • DOCK Partners;
  • DOCK Bank Partners (Pix Direct Partner);
  • DOCK;
  • BACEN;
  • PSP (Grantor);
  • User (Grantor).

The flowchart below presents the complete experience of Key Update or Key Claim in detail.

🚧

Image Quality

If you have difficulty accessing the flowchart below, click here to access the image in a higher resolution.

Key Update or Key Claim flowchart.

Flowchart Captions

Step

Description

1

The end-user accesses the service channel

2

The user requests a DICT Key update

3/4

The DOCK Partner calls the GET /dict/validate endpoint in DOCK, which validates the key

5

The DICT Key is validated

6

DOCK sends the response to the DOCK Partner

7/8

The DOCK Partner receives the message from DOCK and sends the user with the availability of the key

9

If the key is owned by another user, goes to straight to step 23

10

ock sends the response to the partner (Sub Issuer), that sends a message to the user with the availability of the DICT Key

11/12

The DOCK partner calls the PUT /dict endpoint and DOCK receives the request

13

The Pix Direct Partner sends a request to BACEN trough API

14/15

BACEN receives and validates the key information

16

If it is not valid, creates a message of failure to send to the user in step 18

17

If it is not valid, creates a message of success to send to the user in step 18

18/19

BACEN sends the message to the Pix Direct Partner

20/21

DOCK sends the message to the DOCK Partner

22

The DOCK Partner sends the message to the user

23

Starts when the key is owned by another user

24

The user submits a dict claim request by the app

25/26

The DOCK Partner calls the POST /dict/claim-key and DOCK receives the request

27

Verifies if the claim already exists and if it is valid

28

If it is not valid, a message of error is created

29

If it is valid, a request is sent do BACEN

30/31

BACEN receives the request and checks if the key is valid

32

A message is sent to the Pix Direct Partner

33

If it is valid, a message is sent to the PSP of the grantor

34

The user receives the notification

35

The grantor's approval flow starts (continues in step 41)

36

The Pix Direct Partner receives the message from BACEN

37

DOCK API sends the response to the Partner

38/39

The DOCK Partner receives the message and sends the response to the user

40

The user receives a message of failure or pending confirmation

41/42

The grantor accepts the claim of the user by confirming the claim donation

43

BACEN sends the response from the PSP of the user

44/45

The Pix Direct Partner receives the message and DOCK sends the response to the DOCK Partner

46

The DOCK Partner receives the information via webhook (DICT Key)

47/48/49

The DOCK Partner sends the response to the user, which receives the message and send a conclusion message

50

The DOCK Partner calls the POST /dict/claim-key/confirmation endpoint

51/52

DOCK receives the request and verifies if the claim is on the deadline for the conclusion

53

If it is expired, creates an error message to be sent in step 61

54

If it is not expired, sends the message to BACEN

55/56

BACEN receives the message and validates the claim

57

If the claim is not valid, creates a failure message to be sent in step 59

58

If the claim is valid, creates a success message to be sent in step 59

59

BACEN sends a message to the Pix Direct Partner

60

The Pix Direct Partner receives the message

61

DOCK sends a message to the Partner

62/63/64

The DOCK Partner receives the message and informs the user

🚧

Claim Status

All claimed keys start with the "WAITING_GRANTOR" status, as it is pending confirmation from the donor; once confirmed by the donor, the status changes to "CONFIRMED."
The claimant must also confirm it afterward. This confirmation will set the status to "COMPLETED" and the process ensures that the claim is finished.
The endpoint DELETE pix-baas.caradhras.io/dict/v1 allows either the claimant or the grantor to cancel key claims. The cancelation can only be done before the claim status is set to "COMPLETED".

Key Claim Confirmation


The key claim confirmation process makes it possible to receive a key claim notification and donate its user key (Grantor). The following entities are part of it:

  • User (Grantor);
  • DOCK Partner (Grantor);
  • DOCK Bank Partners (Pix Direct Partner);
  • DOCK;
  • BACEN;
  • PSP (Claimant).

The flowchart below presents the complete experience of key claim confirmation in detail.

🚧

Image Quality

If you have difficulty accessing the flowchart below, click here to access the image in a higher resolution.

Key Claim Confirmation flowchart.

Flowchart Captions

Step

Description

1

A notification is sent to the DOCK Partner by Webhook (DICT_KEY_CLAIM)

2

The DOCK Partner receives the claim request

3

The user confirms or cancel the claim request

4

The DOCK Partner calls the POST /dict/clai-key/confirmation/{claimUUID}} endpoint

5/6/7

DOCK receives the message and validates the claim

8

If it is not valid, a error message is created to be sent in 17

9

If it is valid, the Pix Direct Partner sends a request to BACEN

10/11

BACEN receives the request anda validates the information

12

If it is not valid, a error message is created to be sent in 15

13

If it is valid, BACEN sends a message from the PSP of the grantor

14

The PSP claimant receives the message

15/16

BACEN sends a message to the Pix Direct Partner, which receives the information

17

DOCK sends the response to the Partner

18/19/20

The DOCK Partner receives the message and sends to the user

🚧

Key Status

Active keys have the "OPEN" status. Once it goes through a claiming process, its status changes to "WAITING_RESOLUTION". When the process finishes, the donor's key status changes to "HISTORY", since now it belongs to the claimant or it was deleted.

Technical Documentation


To see the technical resources about this product, you can access our technical documentation by clicking on the link below:

Pix (FaaS)
Pix (BaaS)

Updated 3 months ago


DICT Key Experience


Suggested Edits are limited on API Reference Pages

You can only suggest edits to Markdown body content, but not to the API spec.