USCT - Payments (Scenario 2)

UC-P-USCT-002: Payment - Unconditional Social Cash Transfer (non-electronic/cash payments)

UC-P-USCT-002:
Use Case - Payment - Unconditional Social Cash Transfer (non-electronic/cash payments)

From https://github.com/GovStackWorkingGroup/BuildingBlockAPI/projects/1

 

 

ID

UC-P-USCT-002

Name

Payment - Unconditional Social Cash Transfer

Description

The use case implements single scheduled electronic payment to beneficiaries of the programme, irrespective of whether it’s a one time or recurring payment

Verify deposit account information prior to payment transaction

Trigger
(the event that triggers the use case)

Due date of payment has been reached

Preconditions
(list of conditions that MUST be met in order for the use case to be successful)

Electronic payment system is not available

The beneficiary has registered with the SRIS (Social Registry) system

The potential beneficiary’s needs have been assessed and required details captured

The beneficiary has been verified and enrolled into a programme

The beneficiary’s specific payment truck location has been confirmed

 

Note that some preconditions come from the other user journeys and use cases, see steps 2-5 of https://solutions.dial.community/use_cases/unconditional_social_cash_transf/use_case_steps/payment

Data inputs

Reference ID the the social registry programme (from the previous step in the user journey)

Payment due date

List of eligible beneficiaries

Payment amount for each eligible beneficiary

Actors
(a person, a company or organisation, a computer program, or a computer system - hardware, software, or both)

SRIS (social registry information system) screen flow

Payment building block

Workflow building block (for handling the overall process, computing payment amounts and scheduling payments)

ID building block for authenticating beneficiaries at the point of payment

A payment log transactional registry stores payments that have been made

A screen flow application is used to facilitate beneficiary authentication and payments

Normal Course (what happens if the event is triggered and the preconditions have been met)

Extract the beneficiary’s payment details from the SRIS (Social Registry)

A workflow building block computes the payment amounts for the beneficiary

A workflow building block generates a transaction ID for the beneficiary payment

The payment building block prepares an electronic voucher with a cash truck by providing identification details to be verified before a payment is disbursed

Beneficiary goes to the cash truck and presents personal identification documents and the ID block is used to authenticate them

Before a payment is made, the payment log transactional registry is consulted to prevent double dipping

The payment is marked as completed in the payment log transactional registry

Alternative Course
(links to other use cases in case there are different ways how to solve the same use case)

UC-P-USCT-001: Payment - Unconditional Social Cash Transfer (bank payments)

UC-P-USCT-003: Payment - Unconditional Social Cash Transfer (direct payment based on family relationship)

 

If the user’s payments have failed, they can utilize the Registration - Unconditional Social Cash Transfer, see Logical process blueprint

Data output

The list of beneficiaries

IDs, alphanumeric code e.g. EE123456

PNO-EE37702272723

Names, e.g. Raul Carlson

Account numbers, alphanumeric

Amounts tied to the beneficiaries, decimal number e.g. 333.33

Process/session ID (reference to the audit trail record, e.g. 1231289371)

Transaction ID for each successful payment transaction, alphanumeric code, e.g. PAID123456290

Post-Conditions (the success criteria)

Payment response (as code) for each payment transaction

Transaction ID for each successful payment transaction

Each eligible beneficiary has been paid according to scheduled date

Audit trail of the process has been recorded

Exceptions
(error situations)

A payment has not been collected (e.g. due to incorrect payment contact details)

A payment has expired (not collected within the valid timeframe)

A payment has failed due to insufficient funds for withdrawal

Related BBs
(working groups related to that particular use case)

Payment BB - payment processing

Workflow BB - workflow management

Registries BB - data source for the use case

Information Mediator BB - providing interfaces

Security BB - supervision

Identity BB - no relation

 

Cross building block interaction diagram

Diagram source here.

Original DIAL user journey

 

Use Case

User

Agent

Interaction

Processes

 

Unconditional Social Cash Transfer

Target group

Social welfare staff

If a social cash transfer programme has enabled electronic payment processes (e.g. via banks, mobile money, etc.), payments are subsequently paid cyclically according to the programme schedule e.g. often bi-monthly. In the context where a digital financial service system is not employed, each beneficiary would be requested to travel to the nearest designated pay-point* and collect money by programme-specific authentication. In either case, the money is transferred to the selected payment provider or treasury as per generated payroll and is subsequently verified against the individual’s identification of program enrolment.

1. processing beneficiary payment directly to their account, or for generating payroll to deposit payment amounts for withdrawal by beneficiary from designated banking institution(s) / pay-point(s)

 

2. identifying and authenticating individual that is making a withdrawal, or to recall / verify deposit account information prior to payment transaction

 

The original DIAL user journey comes from here: https://solutions.dial.community/use_cases/unconditional_social_cash_transf/use_case_steps/payment