Use of a funcional ID for G2P payments.
| | Wondered if the payments BB weather functional ID would be different for each of the different registrations, @Soban pointed out that the foundational ID would be different for each government programme. Every single provider will get a PSU token which will be given out by tthe ID buidling that has been authorised by the user. @SasiKumar pointed out that when a registration building block asks for a user's name, photograph, and other basic information, and requests permission to link the user's identity to a central payment switch or a bank. There is conset required from the user, If the user consents, the registration building block obtains an access token, which can be used to call APIs to authorize transactions on behalf of the user. The access token can be exchanged for a PSU token specific to the building block that invoked the registration building block, provided that the user's consent is valid and recorded in the ID building block. This mapping is done using a Token Introspection RFC 7662. A three-step process for making payments was proposed, The first step involves registering the beneficiary and issuing a functional ID or PSU token to them, The second step involves populating the beneficiary's payment destination details in the account mapper, and the third step is the actual payment itself.
|
| | In the discussion, it was noted that the Foundational ID never leaves the ID BB and a PSU token which is equivalent to the Functional ID (which is a composite identification token comprising of the Foundational ID, Benefit Programme ID and the Government Entity ID) can be kept in the mapper to identify each eligible beneficiary of a Social Benefit programme. It was noted that since the Foundational ID never leaves the ID BB it is problematic for obtaining the payment account information of the user from the FSP. Soban suggested obtaining the necessary information from the registration building block, which seems to be a separate component of the project. However, it was pointed out that this step will happen after registration, at the time when the eligibility of the person is confirmed by the Social Benefit BB. It was proposed by Vijay that at the time of the confirmation of the eligibility of the person, a notification could be sent by the Social Benefit BB which will request for consent of the user to keep their payment account information in the mapper and an Account Mapper API would be invoked when the user provides his/her consent so they can enter their account information. The person will need to be authenticated before giving their consent. The data provided by the user would be stored in tokenised form in the mapper. Vijay added that to ensure the accuracy of the data entered into the mapper, the payment account information will need to be verified. It was agreed that a validation process would be a necessary step before storing the data in the mapper.
|