-
Notifications
You must be signed in to change notification settings - Fork 8
Home
Below core interfaces & codes help to easily identity functional areas for implementation partners.
Interface | Code | Version | Release Date | Description |
---|---|---|---|---|
Disbursement | DISB | 0.1.0 | Draft | Payment disbursements |
Financial Address Mapper | FAMAP | 0.1.0 | Draft | Manage ID to financial address mapper registry |
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 |
Interface | Code | Version | Release Date | Description |
---|---|---|---|---|
Authorization | AuthZ | 0.1.0 | Draft | Authorization APIs to get required oauth2 compliant authz token to connect |
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 Mgmt or Program Mgmt | Interchangeably used to define issuance mechanisms of a social assistance |
Beneficiary | a person or organization that receives money as part of social assistance |
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.
All communication using G2P Connect specifications have following structure
Field | Description |
---|---|
signature | element holding signature to prove non-repudiability of payload (header & message) between sender & receiver |
header | common header to track messages between sender & receiver for traceability and to track message delivery at transport layer |
message | message to hold transaction request/response entities |
- G2P Connect Integration Specification is designed to be transport layer agnostic viz. JSON entities over HTTPS, event based messaging or file exchanges.
- header field helps in reliable exchange at transport layer between sender and receiver.
- Most of the interactions are asynchronous calls between sender/receiver platforms. Sender initiates with message_id and receiver acknowledges with receipt of the message with ACK/NACK.
- Senders are required to implement callback end points for receiver to POST transaction status/detailed information.
- Additionally, receiver systems are required to implement GET status api's. Sender systems may poll to GET transaction status/detailed information.
- For file based exchange it is recommended to use the JSON payloads. JSON format is hierarchal, self describing to help in integrations.
- 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, Signature element shall be assumed to be first row, JSON header in second row followed by message element.
- File exchange may happen using HTTPS, sFTP or any other file exchange mechanisms.
- G2P Connect JSON based request/response entities shall work as events over messaging infrastructure.
- Trusted sender and receiver systems on a network should create pub/sub end points.
- All dates and timestamps are represented in RFC3339 format including timezone e.g., 2022-12-04T18:01:07+05:30
- All currency codes represented in ISO 4217 format