Field reality
Can teams run it with weak connectivity?
Yes. Vendors can queue card-present claims offline and sync later. Service at the counter does not wait for perfect signal.
§ How it works · field operating model
How card-based aid works on the ground.
Cards in hand
Shops serve offline
NGO pays vendors
ReliefPay is for NGO teams that need a practical alternative to queues, paper vouchers, and hard-to-audit distributions. The field team uses cards, vendors use a phone terminal, and the NGO keeps control of funds and settlement.
01 · NGO decision questions
The questions a field team asks first.
Before a demo, an NGO worker needs to know if this fits real operations: connectivity, funds, dignity, vendor payment, and reporting.
Finance control
Where does programme money sit?
With the NGO. ReliefPay records credits, claims, and settlement references, but vendor payment stays in the NGO's local-fiat process.
Recipient dignity
What does a household experience?
A card at an approved shop. No wallet setup, public queue, seed phrase, or visible voucher explanation at the counter.
Audit trail
What can we show after distribution?
A programme-scoped workbook covering cards, claims, vendors, settlement references, signatures, and proof links when enabled.
02 · Field workflow
The loop your team runs every cycle.
This is the operational map: create the programme, request prepared cards, issue funds, let shops serve people, review claims, pay vendors, and export evidence.
NGO keeps funds
Works offline
No recipient wallet
Audit on request
01
NGOIn view
Create programme + request cards
Name the distribution, set the voucher rule, choose the card quantity, and request prepared cards from ReliefPay.
The programme becomes the boundary for cards, credits, vendors, claims, payments, and audit exports.
02
ReliefPay admin
Prepare and register cards
ReliefPay receives the order, invoices the NGO, registers the NFC cards to the programme, and ships the prepared batch.
This removes scanner complexity from the NGO team before the cards arrive in the field.
03
NGO
Receive cards and fund the cycle
The operator checks active cards, issues the first voucher cycle, and shares the terminal access path with approved shops.
Funding adds spendable card entitlement; programme money still remains in the NGO account.
04
Vendor team
Approve vendors
Vendors request access, ReliefPay or the NGO verifies the shop, and approved vendors receive terminal access for the programme.
Vendor onboarding is controlled so a random shop cannot pretend to be part of the programme.
05
Recipient
Tap card at vendor
The recipient chooses what the household needs within programme rules and taps at the counter like any other customer.
Dignity matters here: no public voucher queue, no public explanation of need.
06
Vendor
Queue and sync claim
The shop enters amount and category, validates the card-present claim, serves the household, and syncs immediately or when connectivity returns.
The balance check protects the card limit; bad network should slow sync, not stop service.
07
Operator
Review claims in Monitor
Synced claims land in Monitor with balance, risk, location, and queue-seal checks. Valid claims are approved for Pay.
The operator should see exactly what needs action and why a claim can or cannot be paid.
08
NGO
Pay vendor + export evidence
The NGO pays vendors from its own account, records the payment reference, and exports the audit workbook when finance or funders ask.
ReliefPay supports the workflow; it does not hold or move the aid funds.
Evidence layer
Base contracts are deployed for verification, while live card hardware and proof recording remain controlled rollouts. Demo links stay available for due diligence.
03 · Money path
The NGO pays vendors. ReliefPay never holds programme funds.
1
NGO budget
Funds remain in the NGO account.
2
Credits issued
Cards receive programme rules and limits.
3
Claim reviewed
Operator approves valid vendor claims.
4
Vendor paid
NGO records local-fiat settlement reference.
This distinction matters for NGO finance and compliance: ReliefPay supports voucher issuance, claim evidence, and settlement records, but it does not become the custodian of relief money.
04 · Team responsibilities
Each person sees the part they need.
Programme lead
Approves the programme rules, vendor list, budget period, and reporting expectation.
A clear operational loop instead of a technical architecture diagram.
Field officer
Receives prepared cards, manages blank-card or roster-based distribution, replaces lost cards, and checks which households are active.
Simple next steps: confirm cards, issue the next period, monitor balances.
Vendor
Uses a phone terminal code to validate a card tap, record sale amount and category, then sync claims.
A claim queue and payment expectation, not crypto rails.
Finance officer
Reviews approved claims, pays vendors from the NGO account, records references, and exports audit evidence.
What is due, what is paid, and what can be shared with auditors.
05 · Operational edge cases
The hard questions should be answered upfront.
What if the network is down?
The vendor terminal queues claims locally. When the phone reconnects, claims sync into the operator console for review.
What if a card is lost?
The operator can pause or replace the card in the programme inventory. ReliefPay treats the card as a field credential, not a bank account.
What if a vendor disputes payment?
The console keeps claim amount, category, vendor, timestamp, card proof, review status, and settlement reference together.
What if a donor asks for proof?
Export the audit workbook or open the proof demo. Recipient names and private case details do not need to be public.
What if the NGO wants another round?
Issue the next period, add recipients, link stock cards, continue claims, settle vendors, and export again. The workflow loops.
What does ReliefPay not do?
It does not hold programme funds, force recipients into wallets, publish private identities, or replace NGO settlement control.
06 · One-month pilot
A realistic pilot is small, controlled, and auditable.
Start with 50 cards, 3 vendors, and one region. The goal is not a massive rollout on day one. The goal is to prove that people can choose, vendors can claim, and the NGO can settle and report.
Week 1
Create programme, request prepared cards, and approve pilot vendors.
Week 2
ReliefPay registers cards, ships the batch, and confirms terminal access.
Week 3
Issue credits, distribute cards, and let vendors sync first claims.
Week 4
Review claims in Monitor, pay vendors in Settle, export the workbook.
Demo links for due diligence
If someone asks for technical proof, the proof feed and donor dashboard remain available as direct demo surfaces. They are not the main operator journey.