Zev Credit¶
A centralised spending balance every Zev user has by virtue of having a ZevID account. Earn it from one Zev product (e.g. as a refund, referral reward, or signup bonus), spend it at any Zev product that accepts it.
What it is, from the user's perspective¶
- A balance attached to the user's ZevID account, not to any one product. The same balance is visible across every Zev product that integrates with it.
- Visible in the account portal at
accounts.zevop.com— the user can see their current balance, the grants that make it up (and where each came from), and a history of how they've spent it. - Non-withdrawable — Zev Credit is spending power inside the Zev ecosystem. It cannot be cashed out, exchanged for currency, or transferred between users. This is what differentiates it from a ZevPay wallet, which holds real money.
- Multi-currency aware — a user can hold a Naira balance and a USD balance separately. Each currency is its own pool; the system never auto-converts between them.
How a user earns Zev Credit¶
The Zev product the user is interacting with chooses to issue credit. Today, six sources are recognised across the ecosystem:
| Source | Typical scenario |
|---|---|
| Referral | User refers a friend; the friend signs up; the referrer earns credit. |
| Promo | A promotional campaign awards credit to a target group of users. |
| Prepayment | A user pre-funds future usage of a product (e.g. topping up an account before deploying). |
| Refund | A product refunds a charge as credit instead of (or in addition to) returning money. |
| Goodwill | A support gesture from staff — making a user whole after a service issue. |
| Signup bonus | A welcome grant when a user signs up at a product. |
Each grant can also carry an expiry (e.g. promotional credit that runs out after 30 days) and a scope (e.g. credit that can only be spent at the product that issued it, or universal credit spendable anywhere).
How a user spends Zev Credit¶
When the user is paying for something at a Zev product that accepts credit, the product checks the user's spendable balance for that currency, and applies it to the bill before falling through to other funding sources (e.g. the user's ZevPay wallet or a card). The user sees the credit applied at checkout.
If the credit doesn't cover the full amount, the product collects the shortfall normally. If credit covers it entirely, no other charge is made.
The user can always see their remaining balance and a per-transaction breakdown of how credit was applied in the account portal.
How products participate¶
Each Zev product decides three things:
- Whether to issue credit — and under which sources. ZevCommerce issuing refund-as-credit, ZevCloud accepting prepayments as credit, and a ZevID-issued signup bonus are all examples of the same mechanism with different sources.
- Whether to accept credit — i.e. whether the product offers credit as a payment option at checkout / billing time.
- What scope its issued credit carries — universal (spendable anywhere in the ecosystem) or product-scoped (spendable only at the issuing product).
A product can issue credit only for its own users — it cannot fund a user it has no relationship with, and it cannot spend credit on behalf of another product. A product's credit operations are bound to its own identity within the ecosystem.
Teams and organisations¶
Where a product has the concept of a team / organisation / workspace (e.g. ZevCloud teams, ZevCommerce stores, ZevWorkspace orgs), credit can be held by the team rather than by an individual. The team's owner is the legal holder; the team is what gets billed. When team ownership transfers, the team's credit balance follows the team — not the previous owner.
Constraints that always hold¶
- Credit is never withdrawable to cash.
- Credit is never transferable between users.
- Credit operations are idempotent — replaying the same operation never double-charges or double-issues.
- A debit can never take a balance below zero; the product collects the shortfall through other funding sources.
Where this lives¶
Zev Credit is owned by ZevID — the ledger, the user-portal surface, and the issue / debit / balance operations all live there. Other Zev products consume it as a cross-product capability; they do not run their own credit ledger.
For the engineering interface (internal-API endpoints, scope-binding rules, idempotency semantics) see the ZevID engineering documentation. This page describes the user-facing model that every Zev product participates in.
Referencing this page from a product profile¶
When a product issues or accepts Zev Credit, the product's profile in this repo should:
- State that it participates, in plain English ("ZevCloud accepts Zev Credit as a payment option at billing time; ZevCloud issues credit as a refund alternative.").
- Note the sources it issues under (e.g. refund, promo), without re-explaining the system.
- Link back here for the full mechanism:
[Zev Credit](../../cross-product/zev-credit.md).
The product profile should not duplicate the rules on this page — link to it, then expand on the product-specific part (when credit is offered at checkout, which user flows trigger an issue, etc.).