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 vocabularies covered: 3 value mapping.
Vocabularies
| Vocabulary | System name | Relationship | Coverage | Gaps |
|---|---|---|---|---|
| delivery-channel | paymentModality | Value mapping | 2/5 mapped | 5 not covered |
| payment-status | BatchTransactionStatus (implied) | Value mapping | 3/3 mapped | 5 not covered |
| voucher-status | VoucherStatus (integer codes, labels inferred) | Value mapping | 6/7 mapped | 1 not covered |
Documented gaps
PublicSchema items that GovStack Payments BB does not model, with the documented reason.
| PublicSchema item | Reason |
|---|---|
| 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. |
Help improve this page
Highlight any text on this page to leave an annotation. Join our review group to get started.
If you have a GitHub account, click the feedback icon next to any section heading to report a specific issue.