2026-05-28 Meeting notes

Clarification of API Gateway and Info Mediator Roles

David Higgins

• Discussed the distinction between the API Gateway and Info Mediator in the payment system, confirming with the IM team that the API management system is a requirement and clarifying its implementation and security boundaries.

  • API Gateway vs Info Mediator: Vijay raised a question about whether the API Gateway was implemented separately or if the Info Mediator was used to fulfill its role. David clarified that the payment specification requires an API management system, and while Info Mediator was involved, the API Gateway's security boundary is still defined separately

  • Security Component Definition: David explained that the team is not redefining the Info Mediator within their building block but is instead specifying the necessary security component that sits at the system boundary, ensuring compliance with requirements.

  • Requirement Specification: The group agreed that the API management system is a required component for any solution, and this should be explicitly stated in the requirements, with Vijay confirming the need to mark it as required.

Review and Mapping of Payment Requirements in Excel: Payments BB - Govstack 2.0 - Google Sheets

David Higgins Mauree, Venkatesen Kibuuka, Arnold

David Higgins provided updates on the Excel sheet mapping key digital functionalities, discussed challenges in aligning requirements, and collaborated with @Vijay and Kibuuka, Arnold on refining the mapping, especially for security and orchestration requirements.

Updates: David updated the key digital functionalities column in the Excel sheet, aligning items where possible and highlighting areas with overlap or ambiguity, such as line 11, item 7, which could not be clearly mapped.

Testability and Observability: David began marking requirements for mutability and observability but encountered issues due to the way requirements are currently written, noting that many are operationally observable but not testable, and suggesting a rewrite to create testable cases.

Security Requirement Placement: The team discussed whether security requirements should be specified within their group or handled by another group, with David suggesting that requirements involving secure communication should be split into functional and security components, and placed in the appropriate section.

Requirement Duplication and Splitting: David and Vijay agreed that some requirements, such as secure notifications, should be split into separate testable requirements to avoid duplication and clarify their scope.

Structuring and Extending Payment Building Block Requirements:

David Higgins Mauree, Venkatesen Ali González

Discussed how to structure core and extension requirements for the payments building block, including handling G2P, B2G, multi-currency, and vouchers, and how to represent extensibility and mutability in the documentation.

Core vs Extension Requirements: Arnold questioned what remains in the core payments building block if extensions like G2P, multi-currency, and vouchers are separated, and David clarified that core components include orchestration, security, and audit logging, while extensions cover specific functionalities.

Layered Requirement Structure: David explained the approach of using a tree structure for requirements, where base requirements are extended and made required or optional in specific use cases, and referenced similar work done in the registries building block.

Security and Audit Logging Placement: David emphasized that security and audit logging should be part of the core requirements, typically placed in the CFR section, and not treated as extensions, aligning with recent changes in requirement structuring.

Handling of G2P and B2G Use Cases in Requirements

Mauree, Venkatesen David Higgins

The group discussed how to differentiate and map requirements specific to G2P and B2G use cases, considering the need for a use case column and how to handle batch and bulk payment functionalities.

G2P and B2G Requirement Mapping: David noted that many requirements currently focus on G2P, with B2G added later, and suggested reviewing and adding missing B2G requirements as needed, with Venkatesen agreeing to this approach.

Batch and Bulk Payment Handling: The team discussed whether batch and bulk payment requirements should be grouped under payment orchestration or separated by use case, with David proposing the addition of a use case column to clarify applicability.

Extension Architecture Options: David outlined two options for handling extensibility: creating recommended requirements with extensions for specific use cases, or using a table with a use case field allowing multiple selections, and the group considered both approaches.