Home

G2P Connect Interfaces

Below interface codes help to easily identity functional areas for implementation partners

Interface	Interface Code	Version	Release Date	Description
Authorization	AuthZ	0.1.0	Draft	Guidelines on Authentication & Authorisation
Disbursement	DISB	0.1.0	Draft	Initiate disbursement, check disbursement status, etc.,
Financial Address Mapper	FAMAP	0.1.0	Draft	Link, unlink, resolve, status, etc.,
Identity	ID	0.1.0	Draft	APIs to foundational identity authentication & eKYC services
Scheme Management	SM	0.1.0	Draft	APIs to manage schemes - define, eligibility/disbursement rules, sponsor a/c linking, etc.,
Beneficiary Management	BM	0.1.0	Draft	APIs to manage Beneficiaries - enrol, check eligibility, digital credentialing, etc.,
Digital Credentialing	DC	0.1.0	Draft	APIs to issue, manage digital verifiable credentials to eligible beneficiaries

Overview

G2P Connect Integration Specifications open source effort to standardise the key integrations across functional categories defined in G2P Connect Technology Architecture Blueprint.

G2P Connect Integration Specification assumes interaction between DPG projects, Proprietary/Existing systems may vary due to underlying landscape across countries. For e.g.,

a. Few countries may have centralised payment switch operated by central bank while others may operate directly with financial institutions.
b. Countries may decide to manage ID to Financial Address mapping either at Payment Switch layer or Financial Institution(s) or Beneficiary Management Platforms or an independent entity, etc.,

For these reasons G2P Connect is flexible to enable DPG projects, Proprietary/Existing systems to orchestrate the flows based on various use case scenarios that are specific to country's operating requirements.

Message Structure

All communication using G2P Connect specifications have following structure

Field	Description
header	common header to track messages between sender & receiver, traceability, encryption/digital signing
message	message to hold transaction request/response entities

Transport Protocol

1. G2P Connect Integration Specification is designed to the transport layer agnostic viz. JSON entities over HTTPS, event based messaging or file transfers.
2. header field helps in reliable exchange at transport layer between sender and receiver.

Communication Protocol

1. Most of the interactions are asynchronous calls between sender/receiver platforms. Using header field, sender initiates with message_id and receiver acknowledges with status & transaction_id as immediate response.
2. Senders are required to implement callback end points for receiver to POST transaction status/detailed information.
3. Additionally, receiver systems are required to implement status api's. Sender systems poll to GET transaction status/detailed information.

File based processing

1. For file based exchange it is recommended to use the JSON payloads. JSON format is hierarchal, self describing to help in integrations.
2. If a country has use cases to use other formats (e.g. CSV) then it is recommended to use the same JSON definitions by flattening each root entity as a file row. In this scenario, JSON header should be assumed to be part of the first row in CSV file.
3. File exchange may happen using HTTPS or sFTP or storage devices like memory sticks.

Event based processing

1. G2P Connect JSON based request/response entities shall work as events over messaging infrastructure.
2. Trusted sender and receiver systems on a network should create pub/sub end points.

Acknowledgments