GovStack Payments BB unreviewed
https://govstack.global/specifications/payments/
GovStack Payments Building Block specification.
This page shows how GovStack Payments BB vocabulary codes map to PublicSchema canonical values. If you work with GovStack Payments BB and spot an error, please report it.
3 vocabularios covered: 3 correspondencia de valores.
Vocabularios
| Vocabulario | Nombre en el sistema | Relación | Cobertura | Brechas |
|---|---|---|---|---|
| delivery-channel | paymentModality | Correspondencia de valores | 2/5 correspondencias | 5 sin cobertura |
| payment-status | BatchTransactionStatus (implied) | Correspondencia de valores | 3/3 correspondencias | 5 sin cobertura |
| voucher-status | VoucherStatus (integer codes, labels inferred) | Correspondencia de valores | 6/7 correspondencias | 1 sin cobertura |
Brechas documentadas
Elementos de PublicSchema que GovStack Payments BB no modela, con la razón documentada.
| Elemento PublicSchema | Razón |
|---|---|
| enrollment-status | The Payment BB does not model program enrollment. Enrollment is managed by the upstream Source BB (e.g., OpenSPP, openIMIS). |
| eligibility-status | The Payment BB does not model eligibility decisions. Eligibility is determined by the upstream Source BB before payment instructions are sent. |
| entitlement-status | The Payment BB receives payment instructions but does not track entitlement lifecycle. Entitlement management belongs to the Source BB. |
| grievance-status | The Payment BB does not include a grievance or complaints module. |
| grievance-type | The Payment BB does not include a grievance or complaints module. |
| referral-status | The Payment BB does not model inter-program referrals. |
| gender-type | The Payment BB does not collect or store demographic data. Person identity is limited to a functional ID for payment routing. |
| sex | The Payment BB does not collect or store demographic data. |
| marital-status | The Payment BB does not collect or store demographic data. |
| education-level | The Payment BB does not collect or store demographic data. |
| relationship-type | The Payment BB does not model person-to-person or person-to-group relationships. |
| group-type | The Payment BB does not model households, families, or groups. It operates at the individual beneficiary level for payment routing. |
| group-role | The Payment BB does not model group membership or roles. |
| identifier-type | The Payment BB uses a single opaque functional ID (payeeIdentity/payeeFunctionalID) for beneficiary identification. It does not categorize identifier types. |
| hazard-type | The Payment BB does not model hazard or shock events. |
| event-severity | The Payment BB does not model event severity or priority. |
| event-certainty | The Payment BB does not model event certainty. |
| targeting-approach | The Payment BB does not model targeting methodology. Targeting is done by the upstream Source BB. |
| conditionality-type | The Payment BB does not model benefit conditionality. |
| voucher-format | The Payment BB does not distinguish physical vs. electronic voucher format. Vouchers are created with a serial number and encrypted secret number; the delivery mechanism to the beneficiary is outside the BB scope. |
| benefit-frequency | The Payment BB does not model payment frequency. It executes individual batch payment instructions on demand; scheduling and frequency are managed by the Source BB. |
Ayude a mejorar esta página
Resalte cualquier texto en esta página para dejar una anotación. Únase a nuestro grupo de revisión para comenzar.
Si tiene una cuenta de GitHub, haga clic en el icono junto a cada encabezado de sección para reportar un problema específico.