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 vocabulaires covered: 3 correspondance de valeurs.
Vocabulaires
| Vocabulaire | Nom dans le système | Relation | Couverture | Lacunes |
|---|---|---|---|---|
| delivery-channel | paymentModality | Correspondance de valeurs | 2/5 correspondances | 5 non couvert(s) |
| payment-status | BatchTransactionStatus (implied) | Correspondance de valeurs | 3/3 correspondances | 5 non couvert(s) |
| voucher-status | VoucherStatus (integer codes, labels inferred) | Correspondance de valeurs | 6/7 correspondances | 1 non couvert(s) |
Lacunes documentées
Éléments de PublicSchema que GovStack Payments BB ne modélise pas, avec la raison documentée.
| Élément PublicSchema | Raison |
|---|---|
| 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. |
Aidez-nous à améliorer cette page
Surlignez du texte sur cette page pour laisser une annotation. Rejoindre notre groupe de révision pour commencer.
Si vous avez un compte GitHub, cliquez sur l'icône à côté de chaque titre de section pour signaler un problème précis.