Closed-loop brand codes — app stores, gaming, streaming, retail — bought by businesses from a prepaid B2B wallet, delivered sealed, and accounted for journal by journal.
Counted from the codebase, not from a pitch deck. The sandbox runs the whole flow against a simulated supplier that also misbehaves on purpose.
The sandbox catalogue mirrors the categories we are contracting for: app stores, gaming, streaming. Each SKU carries its region, denomination, expiry rule, resale flag and terms.
App-store credit · ₹100, ₹500, ₹1,000
Store wallet · ₹1,000, ₹2,000
Gift card · ₹1,000
Wallet code · ₹800
Gift card · ₹500
Via the supplier network after go-live, with India-region rights in writing.
Text monograms only — brand names are trademarks of their owners and imply no endorsement.
Delivered, partly delivered, quarantined, held for the supplier — each one a signed, sequenced event your webhook receives. Illustrative data, real contract.
Add gaming and app-store credit next to mobile recharge without holding supplier float yourself.
Sell codes at the counter through TapProof, reveal behind the merchant PIN, earn a commission. Coming.
Turn points into brand codes delivered by API, with one reveal per code and a full audit trail.
Pay cashback or employee perks in brand codes, reconciled to the paisa against your own ledger.
The vault, the ledger and the order engine are shared. Each channel only changes where the code is revealed and who is allowed to reveal it.
The /v1 API and the partner portal. Prepaid B2B wallet, quotes, idempotent orders, single reveal, signed webhooks.
A “Sell vouchers” tab inside TapProof. The counter reveal sits behind the app PIN; the merchant commission gets its own ledger account.
A UPI-only catalogue inside VIKAM, device-bound reveal, velocity limits and a consumer dispute flow.
Landed cost from supplier cost and FX; your price from face value minus your discount — held until the quote expires.
Under a lock on your wallet: status, tier caps and balance checked, the amount moved from available to reserved. Never negative.
Our order id is the supplier reference, so the supplier itself dedupes. A timeout is never retried as a new purchase.
Region, denomination, expiry and duplicates checked. Good codes sealed; bad ones quarantined and claimed back.
Plaintext only on an explicit reveal, once per code, audited with the device id. A second attempt returns the original timestamp.
Delivered units settle reserved → supplier float + margin; undelivered units release to available in the same transaction.
Every order walks the same state machine. Each transition is validated, recorded with a reason, and emitted as an event.
CREATEDChecked against your status, tier caps and balance. Nothing has moved yet.
WALLET_RESERVEDThe total moves from available to reserved under a lock on your wallet.
SUPPLIER_PENDINGBought once, with our order id as the supplier reference. Money stays reserved.
FULFILLEDReserved settles to supplier float and margin. Every code sealed.
PARTIALLY_FULFILLEDYou pay for delivered units only; the rest is released to available.
FAILEDThe full amount is released back to available. No codes, no charge.
SUPPLIER_AMBIGUOUSThe supplier timed out or answered unclearly after we sent the order. Money stays held — never refunded blind, never re-bought. A resolver asks the supplier about our reference and settles to one of the three finals; if the supplier never received it, the order fails and releases after a grace period.
The same arithmetic the pricing code runs, in integer paise. Foreign cost is converted with a decimal library and always rounded up, so we never under-cost a code.
A rate older than the configured age makes the SKU unquotable rather than guessing.
If price minus landed cost falls under the floor, the SKU is shown as unavailable.
SKUs whose codes would expire within 60 days are not quotable.
A quote fixes the unit price until it expires; an expired quote returns a fresh one.
Double-entry and append-only. Balances are sums of postings; the database rejects a journal that does not balance and any attempt to edit one.
| Journal | Account | Dr ₹ | Cr ₹ |
|---|---|---|---|
| Reserve | partner:available | 980.00 | |
| partner:reserved | 980.00 | ||
| Settle | partner:reserved | 980.00 | |
| supplier:float | 927.88 | ||
| revenue:voucher_margin | 52.12 | ||
| Release · on failure | partner:reserved | 980.00 | |
| partner:available | 980.00 |
Top-ups: Dr bank clearing / Cr partner available, idempotent on the bank UTR. Bad codes: Dr supplier claims / Cr supplier float.
Per-code envelope encryption bound to its context, masked everywhere else. The reveal flips the code, decrypts and audits in one transaction.
Append-only journals, balanced by the database. Top-ups are idempotent on the bank UTR. Corrections are new journals, never edits.
When a supplier times out, money stays reserved while a resolver asks the supplier about that exact reference — then delivers or releases.
The same Idempotency-Key returns the original result. A different body under the same key is rejected.
Asked for 10, got 7: you get 7, pay for 7, and 3 are released to your balance in the same transaction.
Daily and monthly caps are enforced at order time, inside the same lock that reserves the money.
Each code is encrypted with its own random AES-256-GCM data key; that key is wrapped by a key-encryption key. The ciphertext is bound to its order and code, so it cannot be moved to another record.
Revealing flips the code, decrypts and writes the audit row in one transaction, with the device id. A second attempt returns the original timestamp, and is audited too.
Orders, events, webhooks and our own console show ****-****-1234. Plaintext is never logged, never put in events, and never stored unsealed.
New codes seal under the active key; older codes still open under the key that sealed them, so rotation needs no downtime or re-encryption window.
No passwords. A sign-in link works once, expires quickly, and only in the browser that requested it — a forwarded link is useless.
The console accepts @fluxusforge.in accounts with roles: owner, operations, finance, read-only support. Staff never see plaintext codes.
What Codeproof is and is not, and which pieces are still in progress before partners go live.
| Area | Position | Status |
|---|---|---|
| Product | Closed-loop brand codes sold to businesses. Not a PPI, no consumer wallet, no stored value for individuals. | By design |
| GST | Voucher treatment per CBIC Circular 243/37/2024, with a separate taxable fee line. Invoice template awaiting CA sign-off. | Pending |
| TDS | 194Q tracking on purchases, matched to 26AS quarterly. | Pending |
| DPDP | Consent and retention: sealed codes purged 90 days after reveal; the hash and audit trail are kept. | Pending |
| Grievance | A named grievance officer and published SLA before partner go-live. | Pending |
| KYC | Tiered onboarding T0–T4 with caps enforced at order time; KYC flows run through the Fluxus Forge onboarding team. | Caps live · KYC manual |
Bearer-key REST with money as integer paise. Webhooks cover everything else — delivered, partly delivered, failed, held, quarantined, wallet credited.
GET /v1/catalogcurl -s https://codeproof.fluxusforge.in/v1/catalog?brand=Google%20Play \ -H "Authorization: Bearer $KEY" # → items[]: sku, faceValueMinor, unitPriceMinor, available
POST /v1/quotescurl -s https://codeproof.fluxusforge.in/v1/quotes \ -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \ -d '{"sku":"GPLAY-IN-1000","qty":1}' # → quoteId, totalMinor "98000", expiresAt (+60 s)
POST /v1/orderscurl -s https://codeproof.fluxusforge.in/v1/orders \ -H "Authorization: Bearer $KEY" -H "Content-Type: application/json" \ -H "Idempotency-Key: $(uuidgen)" \ -d '{"quoteId":"…","clientReference":"txn-8841"}' # → 201 FULFILLED · 202 SUPPLIER_AMBIGUOUS — retry with the same key
POST …/codes/{codeId}/revealcurl -s -X POST \ https://codeproof.fluxusforge.in/v1/orders/$ORDER/codes/$CODE/reveal \ -H "Authorization: Bearer $KEY" -H "X-Device-Id: pos-12" # → { code, revealedAt } — once. Again → 409 ALREADY_REVEALED
| Typical voucher API | Codeproof | |
|---|---|---|
| Code delivery | Plaintext codes in the order response | Masked codes; plaintext through one audited reveal |
| Supplier timeout | Retry the purchase and hope | Ambiguous state, money held, settled by a status check |
| Balances | A balance column updated in place | Double-entry journals; balances are sums |
| Callbacks | Unsigned, unordered, best-effort | HMAC-signed, sequenced per partner, replayable |
| Onboarding | Manual KYC, one limit for everyone | Tiered limits T0–T4 enforced at order time |
Every partner is one legal entity with one wallet. Tier and caps are set at onboarding and enforced on every order.
| Tier | Who | KYC | Monthly cap | Channels |
|---|---|---|---|---|
| T0 | Consumer — individual, own use | Mobile OTP + PAN + device binding | ₹25K / month, ₹10K / day, 3 codes / day | VIKAM / web |
| T1 | Reseller — proprietor or freelancer | Aadhaar eKYC with liveness + PAN + penny-drop + selfie | ₹2L / month | App + portal |
| T2 | Proprietorship, partnership or LLP | Udyam or GST + firm PAN + partner KYC + bank in firm name + premises proof | ₹25L / month (₹5L without GST) | Portal + API |
| T3 | Private limited company | CIN + MCA directors + board resolution + GST + company PAN + bank in company name + UBO ≥ 10% | ₹5Cr / month, raised on history | API + portal |
| T4 | Enterprise — aggregators, fintechs, corporates | T3 + your AML policy + site or video visit + addendum | Custom, optional credit line | API |
Codeproof is in build. The core — catalogue, pricing, orders, the single-reveal vault, the double-entry ledger and the partner API — runs today against a simulated supplier. Partner access is by invitation while we complete supplier contracts and go-live checks.
No. Codeproof sells closed-loop brand codes to businesses. Partners hold a prepaid B2B balance with us to buy codes; there is no stored value for individuals and no consumer wallet.
By bank transfer (UPI, NEFT, RTGS or IMPS) to your own virtual account, whose details you receive during onboarding. Every credit is matched to its bank UTR and can never be applied twice. Cards and net-banking are not accepted.
The order becomes “Confirming with supplier”. Your money is held — not spent and not refunded blind — while our resolver asks the supplier what happened to that exact order reference. It then settles to delivered or refunded. We never re-buy, so you are never charged twice.
Codes are envelope-encrypted per code the moment they arrive and are masked everywhere, including in our own console. Plaintext exists only in the one reveal response you request, and every reveal attempt is audited.
No. Each code is revealed exactly once; a second reveal returns 409 ALREADY_REVEALED with the original time. Hand the code to your customer from that one response — we cannot show it again, and neither can our staff.
You prepay your own B2B wallet with Fluxus Forge by bank transfer. An order reserves the amount, settles only for codes actually delivered, and releases the rest. Your balance is always the sum of your ledger entries, which you can read at any time.
Undelivered units are released to your available balance in the same transaction that finalises the order — automatically for failed and partly delivered orders. Withdrawals from the wallet go only to your registered, verified bank account.
The sandbox runs the real order engine, vault and ledger against a simulated supplier. Codes are fake and no money moves. Some SKUs misbehave on purpose — partial delivery, timeout, out of stock, wrong-region codes — so you can build against every outcome before go-live.
Every code is validated before it is sealed — region, denomination, expiry of at least 60 days, duplicates. A code that fails is quarantined, you are not charged for it, and we raise a claim against the supplier.
These are the objectives the system is built against. They are targets, not achievements — there is no production traffic yet.
Tell us who you are and how you would distribute codes. We review every request and reply by email.