Skip to content
Vijay Vujjini edited this page Feb 16, 2023 · 23 revisions

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 Authorization APIs to get required oauth2 compliant authz token to connect
Disbursement DISB 0.1.0 Draft Payment disbursements
Financial Address Mapper FAMAP 0.1.0 Draft Manage ID to financial address maps
Identity ID 0.1.0 Draft APIs to access authentication & eKYC services
Scheme Management SM 0.1.0 Draft Manage scheme/program
Beneficiary Management BM 0.1.0 Draft Manage beneficiaries
Digital Credentialing DC 0.1.0 Draft Issue, manage digital verifiable credentials

Terminology

Term Description
sender Initiator of request by any application/service/system/platform using G2P Connect compliant interfaces
receiver Receive of request by any application/service/system/platform using G2P Connect compliant interfaces and either process or forwards downstream with minimal or no validations as a Sender
payer a person or organization that gives money from a store of value account
payee a person or organization that receives money into a store of value account
fa Financial Address to uniquely identify person/organization to a store of value account
Scheme or Program Interchangeably used to define issuance mechanisms of a social assistance
Beneficiary a person or organization that receives money as part of social assistance

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.

Data Formats

  1. All dates and timestamps are represented in RFC3339 format including timezone e.g., 2022-12-04T18:01:07+05:30
  2. All currency codes represented in ISO 4217 format

Acknowledgments

Clone this wiki locally