...
Agenda | Presenter | Duration | Discussion | ||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|
Review pending action items | 10 minutes | TECH-654: Updates based on technical reviewIN PROGRESS
TECH-670: Candidate ProductsIN PROGRESSCandidate Products - COMPLETE
Feedback from other participants. Please document any feedback/action items here: Egypt Deep Dive Takeaways
| |||||||||
Status update | 20 minutes |
| |||||||||
BB deep dive
| 20 minutes |
Steve - Question from open G2P team, how are we integrating with G2P connect? They had concerns about multiple standards being developed by GovStack and G2P. Is there a plan to build the G2P connect into GS payment hub adaptor? David - The team had discussed with G2P connect but have not yet finalised the full context of what the integration will entail. G2P raised that the adaptor principle we have in GS would need to be hosted and owned by one person in a place. They were interested as GS wants to take that forward and own it within the adaptor layer. Trev - what is thepractical difference between a request for payment and a bill?When we were looking at the BB or the diagram for the building block, it said that we were including a portal in that, does that mean we are defining what web portal should be or is it that we are actually building an actual portal that is actually part of the block that 's is shipping or you get how are we defining that as a building block itself? David - We do provide a portalIn terms of requests to pay, it is envisaged to be in the case of where you go for a service and you were not going to be billed. For instance, bills would be when something is bought, the buyer will be billed, and then needs to go and pay; whereas request to pay might be someone on a government system, buying a construction permit and at that point in time, it doesn't generate an invoice or a bill, but do generate a request to pay, and therefore go into the system. So, no need to go for the whole invoicing loop up front. Re. payment portal - there is payment operation portal. Martin - How is the P2G and G2B information movement planned and what are the external BBs that will be involved? Vijay - When it comes to G2P payment there are other BBs like registration, ID that will be involved. With voucher engine, there will be APIs that will be exposed and likewise for financial details into the account mapper. There will be APIs that will be exposed by payment BB for the registration BB to use at the level of payment hub. There are numbers of APIs that are exposed for the different GS BB to use and also for external entities e.g payment system or other FSP. David - If it all stayed within the GS environment, no actual payment can be made. Therefore, there is need to be egress and ingress into payment systems and switches. Ramkumar - The assumption is that there are administrative APIs that are built on the surface of the payment building block, which are called by the payment portal. These administrative APIs should be included back into the specification. There is need to across the BBs to consider a section on the administrative APIs which few BBs currently have. Also, there are no similar UIs that would be collecting the information required during the registration of the candidate for the account mapper. Is this assumption right that we do not want to build payment related information collection into the registration building block itself but wants it to be associated with the payment BB? David - This assumption is planned for the next phase of the work. | |||||||||
API updates | 10 minutes |