Introduction

OpenG2P platform offers registration of persons into programs via the following interfaces:

1. Mobile registration app

2. Self-registration by a potential beneficiary

3. API-based registration by other systems

Agent-assisted registration supports in areas where connectivity may be a challenge.

Registration can be done for individuals or groups like families, households, schools, etc.

Functional architecture

OpenG2P has a flexible architecture that allows governments and social benefit delivery systems to choose functionalities per their needs. The platform is built to allow inclusion and has supporting features. For example, beneficiaries in remote areas without network connectivity can be registered offline. The platform also supports multiple stages of approval with each approval carried out by a different officer.

Technical architecture

is an open source platform that provides the foundation to build government-to-person (G2P) solutions. The roots of the platform lie in the social benefit delivery systems originally developed in response to the Ebola outbreak in Sierra Leone.

The platform offers people facing processes such as onboarding into schemes, identity verification, and cash transfers to their bank accounts. It also incorporates government department facing features such as the creation of registries and beneficiary lists, eligibility checks, scheme definition, payment disbursement and reconciliation.

OpenG2P is a Digital Public Good () recognized by the DPGA and has received contributions and support from multiple organisations and implementers. Its roadmap includes support for non-monetary benefits, proof of delivery, beneficiary management, secure registries, and decision making support.

The project, co-founded by the Government of Sierra Leone and UNDP and supported by in the early stages, is now housed in, a not-for-profit university in India.

Introduction

The person's information is filled in ODK forms on Android devices and submitted to the backend for further processing. The ODK application is integrated with a QR code scanning application that enables an automatic population of KYC data of the person in the form along with verification of digital signature establishing the authenticity of the card.

Registration Process

• Program creation

• ODK form template creation

• Upload of form to ODK Central

• Assigning forms to agents

A high-level view of the administrator-driven registration approach is given below:

ODK

ODK is an open source toolkit that uses offline forms to collect data. ODK Collect is the client-side app while ODK Central is the server-side app. Learn more about ODK .

Offline Registration Mode

OpenG2P offers mechanisms to carry out registrations on the field in areas where Internet connectivity may not be available.

Offline registration demo

Introduction

In the OpenG2P platform, registration is a series of three processes - intake, recording, and verification. Intake is the process of gathering information from applicants while recording and verification are the processes to add the authenticated information to the . The platform verifies the applicant's details in the background by confirming the identity and demographic details of the applicant digitally.

Registration aims to provide detailed records for in the . It must be noted that at this stage, the people are referred to as applicants or registrants. Once the applicants/registrants pass the eligibility criterion set by the program manager, they become eligible to enrol in the program and are referred to as beneficiaries.

This is a pictorial representation of the OpenG2P registration process.

Introduction

Entitlement is the quantity of benefit that a beneficiary is entitled to receive. For cash transfers, this is money that a beneficiary will receive via either direct bank transfer, mobile wallet, cash at the counter, vouchers or other disbursement mechanisms. Entitlement is defined for each .

Introduction

Enrolment is the process of creating a beneficiary list of individuals or groups by querying the registry and applying eligibility criteria. OpenG2P provides convenient filters and plugins to make the entire process frictionless, convenient and time-saving.

Introduction

The Program Management module offers a rich set of functions to define various beneficiary programs (schemes), enrol beneficiaries based on eligibility, calculate entitlements and disburse benefits to the beneficiaries.

Program definition

Program states

• Created

• Ended

• Reactivated

Target types

A program may be targeted to an individual or a group. A group may be a household, family or any other group to which the program is targeted.

Introduction

At the backend, the ID provided (functional or foundational) during registration is verified by submitting the demographic details and ID number by calling APIs of the corresponding ID system. The response from the ID system could be a yes/no response with optional data like ID token and KYC details.

Verification of MOSIP ID

Introduction

Payment Manager is an interface to connect a downstream payment system, like Payment Hub. Multiple Payment Managers may be configured to connect to different systems. Each configuration is specific to the payment system.

Functionality

The Payment Manager creates batches and payment objects.

Introduction

In a given program, disbursement to beneficiaries is done in cycles. The entire entitlement to a beneficiary may be split into cycles for reasons of availability of funds, certain conditions that the beneficiary has to meet or other factors. Further, the beneficiary list may also undergo a change in different cycles based on updated eligibility criteria.

Cycle definition

Beneficiary list update

Splitting a beneficiary list across cycles

A beneficiary list may be split across cycles such that disbursement to a subset of the list is done in one cycle while for the rest disbursement is done in the next cycle.**

Introduction

Fund Management

Entitlement

Payments

Payment Batches

Program Fund Report

Accounting Journals

Introduction

Notifications to beneficiaries and administrators are a must-have, especially when there are multiple stages of a delivery chain, usually with long time intervals between various stages. The beneficiaries must be informed about their enrolment status, entitlements, disbursements, exit etc. Multiple methods of notifications may be employed like postal and courier service, SMS, email, and messaging apps.

OpenG2P provides in-built support for email and SMS with simple configuration changes. The notifications are triggered at certain default points in the delivery chain, however, depending on the needs of a specific implementation more trigger points may be added.

Introduction

The Payments module consists of several functions to efficiently execute cash transfers to the beneficiaries and report the status of payments. Out of the box, OpenG2P offers payment connectors for Mojaloop and GSMA Mobile Money with flexibility to create custom connectors specific to the payment rails of a country.

Payments are generally executed in cycles and batches.

Payments demo

Test cases and verification

The Excel sheet below lists test cases and their verification status for different versions of software. This is a live sheet, and will have the latest status of verification.

Introduction

OpenG2P integrates with MOSIP to verify the UIN/VIDs provided by individuals as part of the registration process. As a result of the verification, OpenG2P receives a unique token against an individual's UIN/VID along with KYC data. This data is stored in the registry.

There are two ways to obtain the MOSIP tokens:

1. For new registrations that are conducted via ODK form, The MTS Connector is configured to pull data directly from ODK Central and return MOSIP tokens. See .

2. For already existing records in the registry, the is used to trigger a connection with MTS and in turn receive MOSIP tokens for all the records requested.

A typical flow of enrolling a beneficiary by collecting data on the field by an agent, in offline mode, is illustrated below.

Source code

All containing source code are licensed under the terms of .

All trademarks are the property of their respective holders. Other products and company names mentioned may be their respective owners' trademarks and/or service marks.

Introduction

Monitoring the status of programs and registries is vital for program administrators. OpenG2P integrates a that lets users create dashboards of their choice to visualise data. The framework uses open source technology components to create a pipeline of data flowing from the databases to visualisation tools. A sample dashboard is given below:

Introduction

A program may have disbursement done in multiple time cycles with start and end dates for each cycle. Such cycles may be defined and triggered as per the schedule defined in each cycle.

Cycles

Introduction

In each , the payment transactions are done in batches. There could be several reasons for batching the payments. The transaction limits may be imposed by payment switch, or any other entity in the payments chain.

Description

There are 3 types of notification managers available that can be created and then can be configured to the program accordingly.

1. SMS Notification Manager

Introduction

A given program will have certain criteria to consider individuals eligible for that program. Assuming that eligibility can be expressed unambiguously based on an individual's demographic data, a program manager can easily run the criteria on the registry to create a beneficiary list using domain filters and eligibility plugins.

Description

This guide provides the steps to create MTS Connectors.

There are two types of MTS Connectors differentiated based on input types

• Capitalize the first letter of every word in the guide title.

• Use second-person pronouns i.e. you, your, etc. in the instructions/steps.

• It is mandatory to do spelling and grammatical corrections using tools such as Grammarly.

• Use the italicized font for UI elements i.e. dashboard names, button labels, information fields, etc.

• Use the exact name and case for the UI elements.

• Use quotes for a phrase/word if the phrase/word has to be represented as is.

• Provide a link at the first mention of a new/different topic. For example, if the guide is talking about installing the SmartScanner app, and the WireGuard app is mentioned, then provide the link for WireGuard.

• Use clear and crisp images.

• The filename for images should follow the naming convention of every word in lower case, and words separated by hyphens i.e. view-all-programs.png.

Introduction

OpenG2P registry is a single repository containing details of the registrants. The registry uses PostgreSQL for maintaining the information in a single DB table.

The purpose of the registry is to provide a single source of truth to the program administrators and managers. Program administrators can grant access to other program participants to act on this information.

Identification of records

Identification of records in the registry is done with configured . ID can be foundational like MOSIP ID or functional like a voter's card, tax number, driving license, etc.

Individual and groups

Individual registrant information is entered in a single row. Whereas group details are stored in multiple rows in the form of relationships with the head or representative of the group.

Multiple entries

OpenG2P platform supports multiple entries for a registrant in the registry. The intent is to keep all the entries for a registrant and deduplicate later at the program level if required. Multiple entries allow program administrators the flexibility to build a registry without bothering about duplicate entries, especially during a crisis situation such as a flood, earthquake, tsunami, etc. and work on deduplication later using the .

Privacy and security

A registry contains an individual's Personally Identifiable Information (PII) along with very rich demographic data. It is critical that this data is secure and PII is not shared in human-readable form or passed on to other systems without the individual's consent. OpenG2P offers secure and private registries to address this concern.

Security

Data at rest is encrypted using strong cryptographic techniques. The data is decrypted in memory while processing the record such that no trace of the unencrypted data is stored anywhere in the system.

Privacy

Data is anonymised while being displayed in human-readable form (for example, UI screen). Similarly, any query results from the registry are anonymised such that this information cannot be used to specifically target an individual.

Custom registrant information

More often than not, program administrators require additional information about the registrants. However, each row in the database can have only a fixed number of fields. To provide customization, the OpenG2P registry captures the most commonly used fields such as name, age, gender, address, identity, etc. as a fixed number of individual fields. Any additional information is captured as key-value pairs held together in a blob.

Developer References

Guides

FAQs

User authentication

Individual Registration

Group Registration

Introduction

Digital payments infrastructure (DPI) could vary from country to country. It is therefore necessary that social benefit delivery systems have the ability to connect to the prevailing DPI and perform G2P payments efficiently. OpenG2P platform provides flexibility to connect to a payment system by writing custom connectors. By default, the platform offers interoperability with the following:

• Mifos Payment Hub

FAQ

Introduction

On-demand assistance is especially useful for scenarios like urgent surgeries, treatments, and other crises. However, to prevent instances of fraud, it is imperative to do a thorough assessment of beneficiary entitlement. This section details one reference implementation using multiple stages of approvals.

Process

1. The beneficiary logs into and provides details of assistance such as the type and cost of treatment along with the name, address, gender, age, occupation, and family information.

2. The assistance application is reviewed and assessed in multiple stages by the officers designated by the program administrator/manager. At each stage, the designated officer will either approve/reject the application with a valid reason. If the application is rejected at any one of the stages, the approval process stops.

3. After all the designated officers approve the application, the final approving officer will also issue an entitlement voucher. The entitlement voucher has a QR code that can be scanned to view beneficiary entitlement and prove the authenticity of the entitlement voucher.

Reference scenario

This example describes on-demand assistance with multi-stage approval.

Customizations

• The program manager/administrator can custom-assign an assessment officer for each stage.

• Though this example shows three stages, the number of stages can be customized.

• The entitlement voucher can be communicated digitally or printed on paper.

Description

The guide here provides steps to submit reimbursement using Service Provider Portal.

Pre-requisites

The Service Provider Portal user has login access to the portal using MOSIP ID/National ID. The user should be able to scan the QR code from the entitlement voucher using .

Steps

1. Login into the Service Provider Portal using MOSIP ID/National ID. In the example below, the National ID of the Philippines (PhilSys ID) is shown.

1. Upon successful login, you will see the Reimbursements dashboard.

1. Select the desired beneficiary and click on Apply. Applying for the reimbursement takes you to the Submission Form page.

1. The beneficiary details are available by scanning the QR code on the entitlement voucher (also called Guarantee Letter) using the . The scan should show details similar to the format in the image below.

1. Enter the details from the scan into the Submission Form and click Submit. This will show a user prompt to confirm the details. Click Submit.

1. Successful submission will show a confirmation page with details such as the application Id and submission date.

1. You can optionally click Go to Home to view the submitted reimbursements. You should see that the status of reimbursement has changed to Applied.

Description

This guide provides the steps to create a default eligibility manager

Pre-requisites

user should have a Program Manager role.

Steps

1. Navigate to Programs using the menu bar.

1. Click on Configuration and then on Default Eligibility Manager.

1. Click Create a button on the default eligibility manager list view page.

1. Provide the name for the eligibility manager and select the program name from the drop-down for which the eligibility manager is created.

1. Use +Add filter to set eligibility criteria using . You may specify multiple eligibility criteria.

1. Click the Save button to save the eligibility manager and it will be listed under the eligibility manager list view page.

Introduction

OpenG2P can use e-Signet for authentication. e-Signet provides an OIDC interface for authentication while connecting to the MOSIP's IDA services on the backend.

Here, OpenG2P is a Relying Party and the Authentication System is MOSIP. Learn more.

Configure OpenG2P for e-Signet

Refer to the guide .

Description

This guide provides the steps to create Payment Hub EE Payment Manager.

Pre-requisites

The user should have a Program Manager role.

Steps

1. Navigate to Programs using the menu bar.

1. Click on Configuration and then on Payment Hub EE Payment Manager.

1. Click on Create button which will navigate to the Payment Hub EE Payment Manager creation page.

1. In the payment manager creation page provide a name for the payment manager, select the program name, select Automatically Create batch if needed, and all the other configurations will auto-populate and can be changed accordingly.

1. Once the payment manager is saved it will be listed under the payment manager list view page which further can be used under the program configuration for which it was created.

Description

This guide provides the steps to create a Payment Interoperability Layer Payment Manager.

Pre-requisites

The user should have a Program Manager role.

Steps

1. Navigate to Programs using the menu bar.

1. Click on Configuration and then on Payment Interoperability Layer Payment Manager.

1. Click on Create button which will navigate to the Payment Interoperability Layar Payment Manager creation page.

1. In the payment manager creation page provide a name for the payment manager, select the program name, select Automatically Create batch if required, provide the Payment End Point URL and Select the Payee DFSP ID Type.

1. Once the payment manager is saved it will be listed under the payment manager list view page which further can be used under the program configuration for which it is mapped.

Description

This guide will help enrol registrants into a program, who are registered through offline registration and online self-registration process.

Pre-requisites

• The user must have a Program Manager role. See guide.

• There should be registrants with respect to the program

Steps

1. Navigate to Programs using the menu bar.

1. Click on the program name on which enrolment needs to be done.

1. After landing on Program detailed view page, check the beneficiaries section for the registrants who are in draft status.

1. Navigate back to the program list view page and click on Enrol Eligible Registrants to enrol the registrants who are in draft status.

2. Enrolment of registrants will be based on the Eligibility criteria set as per the program.

3. The registrants who pass the eligibility criteria will be enrolled on the program with Enrolled status and those who fail the eligibility criteria will be given Not Eligible status.

Description

This guide will provide the types of payment managers that can be created and then can be configured to the program accordingly.

1. Payment Hub EE Payment Manager

Description

The guide here provides steps to install WireGuard App and activate the tunnel. This app allows users to create an encrypted VPN for secure communication.

Pre-requisites

The user must possess an Android Phone. The user should reach out to the system administrator to generate the Wireguard conf file before proceeding with the installation.

Steps

1. Search for "wireguard" in the Android Play Store.

1. Install the WireGuard app, open it, and click on the + icon to add the tunnel.

1. A list of options will appear from the bottom of the app. Click the Import from file or archive option.

1. Select the WireGuard conf file provided by the system administrator. On successful tunnel creation, the tunnel name will appear at the top of the app.

1. Activate the tunnel in WireGuard.

Introduction

Deduplication refers to the process of removing duplicate entries in the registry, thus avoiding double-dipping, and merging all the demographic fields associated with an individual or a group into a single record.

Deduplication of individuals

Individuals are deduplicated by any of the below methods or a combination of these:

Unique foundational ID

If a country has issued unique foundational IDs (like ) then deduplication is trivial -- there is only one record associated with an ID. For privacy, the foundational ID itself is not stored in the registry. Instead, a or associated with the ID is stored.

Functional IDs

If functional IDs like driver's license, tax number, student ID etc. are accepted while registration, then deduplication across IDs is somewhat challenging if a link between these is not already established and available to the OpenG2P system. In this case, heuristics are applied to demographic data to detect potential duplicates.

No ID

In case registrants were onboarded without an ID, the deduplication is performed using heuristics on demographic data.

Deduplication of groups

Deduplication of groups refers to removing duplicate groups within a type of group like a family, or household. The deduplication method is context-dependent and is configured via rules. For example, if the same family has registered itself twice, it will be flagged as a duplicate. However, there are more complex scenarios - say, an individual appears in two different households while other members are different. Such cases will be flagged based on the configured rules.

Manual adjudication

Resolution of duplicates is generally done via a manual adjudication process, where an authority is visually able to inspect the data and reason for duplication. The authority can then decide whether the case is a duplicate or not based on the process set by the country/department/ministry.

Description

There are 2 types of deduplication managers available that can be created and then can be configured to the program accordingly.

1. ID Deduplication Manager

Description

This guide provides the steps to create a Default Payment Manager.

Pre-requisites

The user should have a Program Manager role.

Steps

1. Navigate to Programs using the menu bar.

1. Click on Configuration and then on Payment Interoperability Layer Payment Manager.

1. Click on Create button which will navigate to the Default Payment Manager creation page.

1. In the payment manager creation page provide a name for the payment manager, select the program name, select Automatically Create batch if required and select the Currency.

1. Once the payment manager is saved it will be listed under the payment manager list view page which further can be used under the program configuration for which it was created.

Description

This guide provides the steps to create an phone number eligibility manager

Pre-requisites

user should have a Program Manager role.

Steps

1. Navigate to Programs using the menu bar.

1. Click on Configuration and then on ID document Eligibility Manager.

1. Click Create a button on the phone number eligibility manager list view page.

1. Provide the name for the eligibility manager and select the program name from the drop-down for which the eligibility manager is created.

1. Click the Save button to save the eligibility manager and it will be listed under the eligibility manager list view page.

Description

There are 3 types of eligibility managers available that can be created and then can be configured to the program accordingly.

1. Default Eligibility Manager

Introduction

OpenG2P is a collaborative effort of several contributors. We welcome contributions to the OpenG2P Project.

Issues

Introduction

This page describes the integration of OpenG2P with the switch enabling cash transfer from one bank (treasury bank, for instance) to an individual's bank account. The connection to Mojaloop is achieved via an intermediate interoperability layer like the of Mifos.

Description

This guide provides the steps to prepare payment after approving the cycle of a program.

Pre-requisites

Introduction

OpenG2P offers the on-demand approach via the Self Service Portal where a person logins via his/her ID and then applies for a program. In self-service mode, typically, OTP would be used for login. In assisted mode, the registering officer may have biometric devices connected to his/her machine, and the registrant can perform biometric authentication in an online manner.

Online registration assumes that an ID verification service is available to connect via APIs and perform verification of the identity of a person. In the case of MOSIP, for e.g, the verification can be done using the solution.

OpenG2P offers a reference implementation of a person facing Self Service Portal that lets a person log in to the portal using a national ID or other IDs, and perform the following functions:

Description

This guide will provide the steps to create an Email notification manager.

Pre-requisites

Description

This guide provides steps to create a new ODK form for a program.

Pre-requisites

Description

This guide will help to provide the form access to the field agent. which helps the agent to download the program form.

Pre-requisites

Description

This guide will help to download the program form on ODK Collect Application running on an Android tablet or phone.

Pre-requisites

Description

The guide here provides steps to install the SmartScanner app. This app allows users to scan the QR code in the entitlement voucher.

Pre-requisites

Description

This guide will provide the steps to create a Fast2SMS notification manager.

Pre-requisites

Description

The guide here provides steps to create a new user and assign a role. This process is typically done by the Administrator.

Pre-requisites

Description

This guide will provide the steps to register beneficiaries through an offline process. is done by the Field Agent.

Pre-requisites

Description

This guide provides steps to create and configure the eligibility manager inside the program.

Pre-requisites

Description

This guide provides steps to create a new portal form for a program. This form will show up on the Self-Service Portal when the user selects a program to apply.

Pre-requisites

Description

This guide provides steps to create and configure the deduplication manager inside the program.

Pre-requisites

Description

This guide will provide the steps to create an SMS notification manager.

Pre-requisites

Description

This Guide will help to create the .

Pre-requisites

Description

This guide provides steps to create an ID Deduplication manager.

Pre-requisites

Description

This Guide will help to create the .

Pre-requisites

Contributor Covenant Code of Conduct

Preamble

OpenG2P was created to foster an open, innovative and inclusive community around open source & open standard. To clarify expected behaviour in our communities we have adopted the Contributor Covenant. This code of conduct has been adopted by many other open source communities and we feel it expresses our values well.

Our Pledge

We as members, contributors, and leaders pledge to make participation in our community a harassment-free experience for everyone, regardless of age, body size, visible or invisible disability, ethnicity, sex characteristics, gender identity and expression, level of experience, education, socio-economic status, nationality, personal appearance, race, caste, color, religion, or sexual identity and orientation.

We pledge to act and interact in ways that contribute to an open, welcoming, diverse, inclusive, and healthy community.

Our Standards

Examples of behavior that contributes to a positive environment for our community include:

• Demonstrating empathy and kindness toward other people

• Being respectful of differing opinions, viewpoints, and experiences

• Giving and gracefully accepting constructive feedback

• Accepting responsibility and apologizing to those affected by our mistakes, and learning from the experience

Examples of unacceptable behavior include:

• The use of sexualized language or imagery, and sexual attention or advances of any kind

• Trolling, insulting or derogatory comments, and personal or political attacks

• Public or private harassment

• Publishing others' private information, such as a physical or email address, without their explicit permission

Enforcement Responsibilities

Community leaders are responsible for clarifying and enforcing our standards of acceptable behavior and will take appropriate and fair corrective action in response to any behavior that they deem inappropriate, threatening, offensive, or harmful.

Community leaders have the right and responsibility to remove, edit, or reject comments, commits, code, wiki edits, issues, and other contributions that are not aligned to this Code of Conduct, and will communicate reasons for moderation decisions when appropriate.

Scope

This Code of Conduct applies within all community spaces, and also applies when an individual is officially representing the community in public spaces. Examples of representing our community include using an official e-mail address, posting via an official social media account, or acting as an appointed representative at an online or offline event.

Enforcement

Instances of abusive, harassing, or otherwise unacceptable behavior may be reported to the community leaders responsible for enforcement at [INSERT CONTACT METHOD]. All complaints will be reviewed and investigated promptly and fairly.

All community leaders are obligated to respect the privacy and security of the reporter of any incident.

Enforcement Guidelines

Community leaders will follow these Community Impact Guidelines in determining the consequences for any action they deem in violation of this Code of Conduct:

1. Correction

Community Impact: Use of inappropriate language or other behavior deemed unprofessional or unwelcome in the community.

Consequence: A private, written warning from community leaders, providing clarity around the nature of the violation and an explanation of why the behavior was inappropriate. A public apology may be requested.

2. Warning

Community Impact: A violation through a single incident or series of actions.

Consequence: A warning with consequences for continued behavior. No interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, for a specified period of time. This includes avoiding interactions in community spaces as well as external channels like social media. Violating these terms may lead to a temporary or permanent ban.

3. Temporary Ban

Community Impact: A serious violation of community standards, including sustained inappropriate behavior.

Consequence: A temporary ban from any sort of interaction or public communication with the community for a specified period of time. No public or private interaction with the people involved, including unsolicited interaction with those enforcing the Code of Conduct, is allowed during this period. Violating these terms may lead to a permanent ban.

4. Permanent Ban

Community Impact: Demonstrating a pattern of violation of community standards, including sustained inappropriate behavior, harassment of an individual, or aggression toward or disparagement of classes of individuals.

Consequence: A permanent ban from any sort of public interaction within the community.

Attribution

This Code of Conduct is adapted from the .

Community Impact Guidelines were inspired by .

For answers to common questions about this code of conduct, see the . Translations are available .

Description

This guide provides steps to create and configure the notification manager.

Pre-requisites

The user must have the Program Manager role.

Steps

1. Navigate to Programs using the menu bar.

1. Click on the program name for which configuration to be done.

1. Navigate to the Configuration section on Program detailed view page.

1. Click on Add a line in the Notification Manager section.

1. Click on the Create button on the Add: Notification Managers pop-up window.

1. Select the notification manager type.

1. Once the name is provided to the deduplication manager, Create and Edit buttons will appear. Click on Create and Edit to create a deduplication manager.

1. Click on the Save & Close button which will save the notification manager to that program under configuration.

Description

This guide provides the steps to create an ID document eligibility manager

Pre-requisites

user should have a Program Manager role.

Steps

1. Navigate to Programs using the menu bar.

1. Click on Configuration and then on ID document Eligibility Manager.

1. Click Create a button on the ID document eligibility manager list view page.

1. Provide the name for the eligibility manager and select the program name from the drop-down for which the eligibility manager is created.

1. Click the Save button to save the eligibility manager and it will be listed under the eligibility manager list view page.

Description

This guide provides steps to create and configure the payment manager.

Pre-requisites

The user must have the Program Manager role.

Steps

1. Navigate to Programs using the menu bar.

1. Click on the program name for which configuration to be done.

1. Navigate to the Configuration section on Program detailed view page.

1. Click on Add a line in the Payment Manager section.

1. Click on the Create button on the Add: Payment Managers pop-up window.

1. Select the payment manager type.

1. If a payment manager is already created (), search and select the same or else once the name is provided to the program manager, Create and Edit buttons will appear. Click on Create and Edit to create a payment manager.

1. Provide the details in the payment manager creation manager.

1. Click on the Save button and then click on the Save & Close button which will save the payment manager to that program under configuration.

Overview

ODK MTS Connector is an OpenG2P Odoo addon that fetches tokenised data from the ODK Central by calling the (MTS) and stores it in the registry.

Features

Description

The guide provides steps to enable and configure the proxy mean test.

Pre-requisites

Description

The guide here provides steps to create a new program. A program is typically created by a Program Manager who can create and administer programs.

Pre-requisites

Description

This guide helps beneficiaries to self-register through the beneficiary portal.

Pre-requisites

Overview

Registry MTS Connector (RMC) is an Odoo addon that fetches MOSIP Auth Token against any record in the registry by calling MOSIP Token Seeder (MTS) and stores the same in the registry.

Features

• Generates MOSIP token against the OpenG2P registry by calling .

• Uses callback delivery type of MTS

• Completely asynchronous execution

Configuration

Context

Creating editable diagrams in open formats using open source tools is challenging. Here, we suggest for creating diagrams and saving them directly in GitHub repository.

Creating new diagram

Description

This guide will provide the steps to create and approve the disbursement cycle under a program.

Pre-requisites

Description

This guide provides steps to create a Phone Number Deduplication manager.

Pre-requisites

This page lists all the technologies used in building OpenG2P. Free and open-source softwares with clear long-term support availability have been chosen. Certain choices can be replaced with other free or commercial options for deployment.