What we owe you
The iGift promise
Seven principles, the obligation each places on us, and how you would catch us breaking it. We publish the test as well as the promise, because a promise without a test is a slogan.
The seven principles
01Cards, not wallets
You see card balances and card actions. A ledger exists underneath; the interface stays gift-centred.
- What it obliges us to do
- Every value is attached to a named card. No screen shows a generic balance.
- How you would catch us
- A screen showing "Balance: ₦12,000" with no card identity has failed this principle.
02Choice for the recipient
A gift can be spent on what it was for, transferred, merged, redeemed, or withdrawn where the card allows.
- What it obliges us to do
- Every permitted action is listed, and disallowed ones are shown with the reason — never hidden.
- How you would catch us
- Hiding an unavailable action is worse than showing it disabled: it reads as a missing feature, not a rule.
03Verified commerce
Only approved businesses may sell. Quality, catalogue freshness and delivery are watched continuously.
- What it obliges us to do
- Admission is a decision with evidence attached. Monitoring does not stop at onboarding.
- How you would catch us
- A store whose quality falls stops receiving traffic before a customer is disappointed, not after.
04Local fulfilment first
Checkout prefers sellers in your state to cut cost and delivery time.
- What it obliges us to do
- Locality biases ranking and recommendation — it never removes an option.
- How you would catch us
- Locality is a default, not a restriction. You can always browse other states explicitly.
05Transparent consequences
Split shipments, cross-state purchases, fees, limits, expiry and restrictions are explained before checkout.
- What it obliges us to do
- Every consequence is disclosed before the irreversible action, in plain language, at the point of decision.
- How you would catch us
- A fee discovered on a receipt is a support ticket. A fee shown before confirmation is a choice.
06Configurable, not hardcoded
Card behaviour, fees, roles, workflows and notifications are rules, not code branches.
- What it obliges us to do
- A new gift type or fee schedule is a configuration change with an effective date and an audit record.
- How you would catch us
- If launching a campaign requires a deployment, the rules engine has been bypassed.
07Trust by default
Sensitive actions use step-up authentication, immutable audit trails and risk controls.
- What it obliges us to do
- Security is applied by risk, not uniformly: friction rises with value, novelty and anomaly.
- How you would catch us
- You should meet a step-up exactly when a stranger would fail it, and rarely otherwise.
When two of them conflict
They do conflict. Full disclosure of fees and restrictions crowds a screen; the simplest checkout is the one that tells you least. So the order is fixed in advance rather than argued case by case.
- Trust
- Transparency
- Choice
- Simplicity
- Speed
Trust beats transparency; transparency beats choice; choice beats simplicity; simplicity beats speed. In practice that means we will show you a fee even when hiding it would make the screen cleaner, and we will keep an option available even when removing it would make the decision quicker.