2023-02-13 - Meeting - G2PConnect for G2P Use cases to be added to Govstack Payments use cases

Attendees

  • @karim.jindani

  • @Avik Ganguly

  • @Manoj VM

  • @Ed Cable

  • @Soban Najam

  • @Mauree, Venkatesen

  • @Simon Eyre

  • @Kibuuka, Arnold

Meeting Note

Agenda

Presenter

Discussion

Agenda

Presenter

Discussion

Differences between G2Pconnect and Govstack Payments BB Usecases

@Soban Najam

@Vujjini

  • The comparison of the APIs revealed that Payments BB does not parse names and addresses in payment details, while G2P has this capability through its onboarding APIs.

  • The payments building block is designed to utilize tokenization for securing user account details.

  • @Vujjini The approach at G2P Connect is to standardize the specifications for each high-level interface as an API, including file interfaces and other protocols. This allows for orchestration in various ways, depending on the country and its unique assumptions and needs. By separating out the implementation logic, the interfaces can be standardized while the API implementation can vary from system to system. This approach enables a modular approach to integration.

  • The error codes for the flows should be provided in the implementation.

  • During the meeting, it was discussed that the approach of generalizing interfaces as APIs would allow anyone to call them, while certain validations can be performed on the interfaces. However, the functionality of the source building block is assumed to be validated, and only the format of the destination account details can be validated. This approach enables a more flexible and modular integration approach, which is why it was adopted. It was also noted that the level of details should be kept inside the payload rather than trying to map everything onto a response code

Meeting recording

Action Items

  1. During the meeting, the key action items was for @Soban Najam to reframe the document using more common terminology to ensure that all stakeholders can understand it. After that, a round of feedback will be conducted to identify any specific response source codes that stakeholders may want. This will enable the group to go into specifics and debate point by point. It was emphasized that this needs to be sorted out at a specification level for each particular point.
  2. @Simon Eyre to forward the invite for the technical meeting to the rest of the team from MIFOs.

 

 

Decision

  1. The decision on error codes to keep the level of details inside the payload was made during the meeting. This approach was recommended, as it is more generic and enables a more flexible and modular integration approach. It was noted that trying to map everything onto a response code can be more complex and less effective. Therefore, this approach has been adopted for its benefits in integration and flexibility.