01
Set up the programme and cards
The NGO creates one programme, chooses the allowance, orders prepared cards, and approves the shops that may serve recipients.
Cards, vendors, claims, payouts, and exports stay tied to one programme.
How ReliefPay works now.
ReliefPay is a card-and-Android voucher system for NGOs. Recipients use cards at approved shops, vendors record claims on the Android terminal, and the NGO keeps control of funds, settlement, and audit evidence.
Live pilot loop
Beate programme
Vendor terminalR70 sale
Card accepted offline (pending)
SyncProof + claim
Queue uploads when connected
BackendAccepted
Green after verification only
NGO settles
Manual or provider-ready payout record. ReliefPay does not hold the programme funds.
cardRP
The field loop
Four moments matter in every aid cycle.
The product is simple on purpose. Cards are issued once, vendors serve people with the Android terminal, and finance only pays claims the backend accepted.
02
Recipient pays with card and PIN
An approved vendor enters the amount, asks for the recipient PIN, and taps the card on the Android terminal.
The card is a programme credential, not a cash wallet. ReliefPay does not hold programme funds.
03
Offline stays pending
If signal is poor, the Android app queues the card-present claim. The screen says pending, not accepted.
CARD ACCEPTED OFFLINE (pending) means goods may be served under pilot rules, but finance waits for sync.
04
Sync, review, pay vendors
When the phone reconnects, the backend checks the claim. Operators review exceptions, finance pays approved vendors, and the programme exports evidence.
Green means backend accepted only. Manual settlement is live; provider-assisted payouts are prepared behind controls.
Offline truth
Pending is useful. Green is sacred.
This is the rule that keeps the system honest: a vendor can serve a recipient during weak signal if the pilot rules allow it, but the claim is not final until the backend verifies it.
At the shop
The Android app can queue the sale.
The vendor sees a pending state and a queued receipt. The app does not pretend the backend has accepted the claim while the phone is offline.
CARD ACCEPTED OFFLINE (pending)
After sync
The backend decides whether it turns green.
The backend checks entitlement, vendor approval, duplicate status, card proof, recipient approval, and programme rules before settlement review.
BACKEND ACCEPTED
Offline proof
The hard parts have evidence, but are still gated.
The real-card proof and staging atomic settlement have passed focused tests. Production offline stays disabled until the reviewed phone-card-staging dry run and pilot decision are complete.
GATED
People and money
Simple for users. Controlled for finance.
The app should not expose everything to everyone. Vendors get the terminal and payout profile. Operators get monitoring, settlement, and audit controls.
NGO budget
Funds remain in the NGO or approved local partner account.
ReliefPay records
Cards, claims, reviews, counters, and settlement references are stored for audit.
Vendor paid
Finance pays the approved vendor through manual bank/mobile-money process or configured payout provider.
Recipient
A card and a short PIN.
No app, wallet, seed phrase, or public voucher queue. The person taps the card and confirms the purchase with a simple PIN.
Vendor
A focused Android terminal.
The shop logs in with a short code, enters the amount, taps the card, and sees pending or accepted states without seeing every card balance in the programme.
NGO operator
Monitor and settlement control.
The operator sees live claims, exceptions, vendor payout readiness, settlement batches, and exportable evidence. The NGO keeps the money.
Current status
What is live, what is gated, and what not to overstate.
The page should match the product. ReliefPay can already explain the operational loop, but the hardened offline path remains controlled until the final pilot gate.
Connected vendor sale
ReadyThe vendor can tap a card, sync immediately, and see backend acceptance when the checks pass.
Offline queue and sync
Built and gatedThe app can hold pending claims and sync later. Offline states remain pending until the backend accepts them.
Card proof
Proven in lab/stagingThe card proof and atomic staging settlement have passed focused tests. Production enablement still needs a reviewed dry run and pilot decision.
Live vendor payout automation
Prepared, not assumedManual settlement is the default. Flutterwave-supported countries can use provider-ready payout setup once finance and configuration gates are complete.
Pilot readiness
The next proof is operational, not another promise.
A real pilot should show the full loop with a real Android phone, real card, staging backend evidence, and no green state before backend acceptance.
Cards are registered to one programme before field use.
Vendors are approved and trained on pending versus accepted.
Recipients know their PIN and can report a lost card.
Finance knows whether settlement is manual or provider-assisted.
Offline proof is run only under the reviewed pilot gate.