Use of vouchers for P2G payments | @Oscar Correia pointed out that Initially envisaged as a physical item, but can also be digital (QR code or number shared via text). The purpose was to provide payment options for those without bank accounts or mobile money accounts. @Oscar Correia also pointed out the voucher design: Vouchers are first pre-activated, then activated. Can be sent via bulk payment or issued during registration. Can be redeemed at registered merchants (for goods/services) or agents (for cash). Redemption can be done with or without authentication. Funds move from a prefunded account to the merchant's/agent's account upon redemption.
@Soban Najam raised the following concerns: If payment value is less than voucher value, either funds provisioned won't be fully utilized, or the voucher would need to be multi-use. Potential issues with reconciliation processes and returning unused funds. c. Consideration of multi-use vouchers
@Oscar Correia proposed the following key Assumption: He also pointed out the following challenges for P2G: If voucher amount is greater than payment amount, tracking balance and adjusting it becomes difficult. Enhancements needed to the current design to allow for partial redemption. Possibility of restricting use cases for the first phase and addressing partial redemption in a future phase.
|
Account Mapper and Bulk Payment Link Discussion:
|
Discussed the handling of financial addresses and onboarding process flow.
@Mauree, Venkatesen pointed out contradictions with requirement specs regarding storing the financial address in the Mapper. @Mauree, Venkatesen proposed getting financial address information from FSPs or from the person directly after authentication. @Soban Najam pointed out that the payment building block can't handle authentication and verification, as they only have a functional ID, which is meaningless without foundational ID or phone numbers. He suggested that the registration building block should handle authentication and verification, exposing a web page or SMS interface for beneficiaries to input their financial address. Soban Najam explained that the registration/registry building block can provide the functional ID at runtime, and the beneficiary doesn't need to know the functional ID. @Mauree, Venkatesen mentioned that the registry building block should handle eligibility verification and notify the user of their application status through the messaging building block. @Soban Najam confirmed that the registry building block will use their API to register in the Mapper. Soban Najam reiterated that the API will be consumed at runtime to post financial information directly into the account Mapper, ensuring that it's not retained elsewhere Further discussion is needed to ensure a shared understanding and alignment on the handling of financial addresses. @Soban Najam shared an example from India, where a centralized and decentralized structure is used for proxies. Aliases can be free text fields or fixed lists, such as email addresses or phone numbers.
|