Tech Guides
Persistent Entities in openg2p-spar-mapper-api
id_fa_mappings
Contains the records for id_value (beneficiary Id) and fa_value (Financial Address) mapping
Column | Description |
---|---|
id_value | This is the Beneficiary ID - that will travel in the G2P Chain. This the beneficiary id for which the upstream PBMS / MIS platforms will create disbursements The id_value is constructed using a construction strategy (decided based on implementation). If the mapper is maintained using the self service paradigm, one of the ways that you can construct the ID Value is using the "auth" attributes from the Login Provider. An OIDC / OAuth2.0 Login provider usually provides the following attributes
If we decide that the Banks update the Mapper, then a suitable construction strategy needs to be arrived at. |
fa_value | This is the Financial Address of the Beneficiary - Usually will represent the Savings/ Checking /Current account of the beneficiary in a Bank. The fa_value should be the full account details, such that this value alone is sufficient to enable a payment transaction into the account using the National Clearing Network. |
name | The name of the beneficiary. It is a good idea to have the name of the beneficiary travel back to the upstream systems as part of the "disbursement settlement status" -- The Disbursement settlement status should be sent by the final destination bank (where the beneficiary is credited). |
phone | Phone number of the beneficiary |
additional_info | This is an extensibility feature - to store additional attributes required in an implementation. The SPAR Self Service - populates this column with the strategy-Id (specifies the strategy used for constructing the fa_value) |
Persistent Entities in openg2p-spar-self-service-api
dfsp_level and dfsp_level_values - are static tables that contain the information pertaining to the Banks (and other financial service providers), their branches. The use of these two tables are explained below using examples
dfsp_levels
id | name | level_type - ENUM | parent |
---|---|---|---|
1 | Bank | bank | 0 |
2 | Branch | branch | 1 |
3 | Account number | account | 2 |
The above data indicates that, to fully express the Financial Address of a Beneficiary's bank account, the self service platform needs to capture 3 attributes for the Financial Address, viz. Bank, Branch & Account
Similarly for a Mobile Number based Wallet, we can think of the following dfsp_level configuration
id | name | level_type - ENUM | parent |
---|---|---|---|
4 | Mobile Wallet Service Provider | mobile_wallet_provider | 0 |
5 | Mobile number | mobile_number | 5 |
For a Email Address based Wallet, we can have the following dfsp_level configuration
id | name | level_type - ENUM | parent |
---|---|---|---|
6 | Email Wallet Service Provider | email_wallet_provider | 0 |
7 | Email address | email_address | 6 |
The self-service-ui uses the api - "get_levels (parent)" to paint the UI fields to capture the input for these attributes - parent = 0, will provide the first level for the FA hierarchy
![](https://docs.openg2p.org/~gitbook/image?url=https%3A%2F%2F3034178245-files.gitbook.io%2F%7E%2Ffiles%2Fv0%2Fb%2Fgitbook-x-prod.appspot.com%2Fo%2Fspaces%252FJZcdob2emEcLMvLyIxqT%252Fuploads%252FIciwizzJJ64ZO0nww7Az%252Fimage.png%3Falt%3Dmedia%26token%3D4939775e-259b-46d4-b665-6031562e72b8&width=768&dpr=4&quality=100&sign=71a7a5a2&sv=1)
dfsp_level_values
For facilitating capture of a Bank Account, we can visualize the following dfsp_level_values configuration
id | name | code | parent | level_id |
---|---|---|---|---|
1 | Bank One | Bank001 | 0 | 1 |
2 | Bank Two | Bank002 | 0 | 1 |
3 | Bank Three | Bank003 | 0 | 1 |
The API - get_level_values (parent = 0, level_id = 1) - will yield the UI a drop down of these 3 banks.
id | name | code | parent | level_id |
---|---|---|---|---|
1 | Branch 001 | Branch001-Bank001 | 1 | 2 |
2 | Branch 002 | Branch002-Bank001 | 1 | 2 |
3 | Branch 003 | Branch003-Bank001 | 1 | 2 |
The API - get_level_values (parent = 1, level_id = 2) - will yield the UI a drop down of these 3 branches for Bank One
login_providers
id | name | login_button_image_url | authorization_parameters | strategy_id |
---|---|---|---|---|
1 | E-Signet | The Image that can be shown on the UI for E-Signet | 1 | |
2 | Keycloak | 2 | ||
The API - get_login_providers - will provide the list of configured login_providers. The UI can then redirect itself to the redirect_url specified for that login_provider for the necessary authentication.
strategy
This table contains the construction and deconstruction strategies to be used for id_value and fa_value - that will be eventually stored in the mapper.
The strategy ID is mapped to the login_provider for ID Strategy.
The strategy ID is mapped to the dfsp_levels for FA Strategy.
Many Banks (and possibly all Banks) may use the same FA Strategy. Similarly, all mobile wallet providers may use a single FA Strategy (different from Banks).
Some examples of construction and de-construction strategies are as follows
ID - Construction Strategy --
ID - Deconstruction Strategy --
FA - Construction Strategy --
FA - Deconstruction Strategy --
APIs
Refer API Reference.
Last updated