LulamisaPay bridges the gap between South African households and the services they can't afford upfront — electricity, water, traffic fines, airtime — using the phone app they already have.
¹ DataReportal: Digital 2025 South Africa · ² Auditor-General SA: MFMA 2022/23 Report · ³ NCR Consumer Credit Market Report (quarterly)
Market Opportunity
Millions of South Africans face electricity cut-offs and traffic fines they can't pay in a single lump sum. The existing payment rails don't help them. We do.
Buy Now, Pay Later (BNPL) is a short-term credit product where the customer receives the service immediately but repays in instalments over weeks or months — interest-free or at low interest, depending on the provider. The customer applies through their BNPL provider's checkout page; approval is instant. LulamisaPay receives confirmation of the approved transaction and pays the bill holder on the spot. The BNPL provider then collects the repayments from the customer and settles the full amount back to LulamisaPay on an agreed schedule.
Customer Experience
Service selection, cart, and delivery live entirely in WhatsApp. The only step that leaves WhatsApp is the payment itself — a link opens the BNPL partner's checkout page or a card payment portal in the browser, then the customer returns to WhatsApp for their token and invoice.
Architecture
LulamisaPay is the orchestration and float layer — managing the conversation, routing payments, paying bill holders, and triggering service delivery. Partners plug in via simple APIs.
How Money Moves
LulamisaPay acts as the float provider. Bill holders (Interfile, PayCity, Eskom…) are paid immediately from LulamisaPay's prefunded account or credit card on file. BNPL settlement flows back to LulamisaPay on an agreed cycle — the customer never touches the bill holder's portal.
A secure checkout link is sent to the customer's WhatsApp. Tapping it opens the BNPL partner's checkout page or a card payment portal in the browser — card data goes directly to the payment provider, never to LulamisaPay. The customer returns to WhatsApp after payment.
The BNPL system makes the credit decision. A signed PAID callback is sent to LulamisaPay. Nothing irreversible happens on LulamisaPay's side until this arrives.
High-value transactions pause here before value is handed over — protecting against a PAID webhook that later reverses before the irreversible vend.
LulamisaPay draws from its prefunded balance at the bill holder — or the bill holder charges LulamisaPay's credit card on file, whichever method the provider supports. The customer is not involved in this step at all.
Electricity token issued, fine cleared, account credited. The bill holder vends immediately once payment clears on their side. Receipt + invoice sent to WhatsApp.
The BNPL provider's batch settlement transfers the full checkout amount to LulamisaPay's bank account. LulamisaPay retains the service fee; the principal recovers the float advance. Float gap is now closed.
Principal recovered on settlement · Service fee retained as revenue · Net float tracked per-transaction in the reconciliation API
Partner Value
LulamisaPay is built around the specific needs of BNPL providers and bill-holder service delivery partners. Select your category.
Identity captured once, AES-256 encrypted. Every transaction is tied to a verified SA citizen.
Rolling 24h caps on transaction count and value per account. New-account limits block SIM-swap cash-out.
Transactions above a threshold are held for manual review before the irreversible vend.
Duplicate PAID webhooks never result in a double charge — enforced by a DB-level partial unique index.
There are two models — whichever fits your platform:
LulamisaPay maintains a float balance on your platform. When a transaction is triggered, LulamisaPay draws from that balance. You remit a top-up when the balance drops below an agreed threshold.
LulamisaPay registers a card at your payment gateway. Each triggered transaction is billed to LulamisaPay's card in real time. No prefunded balance required.
In both models the bill holder is paid before vending — zero credit risk for you.
POST /vend or equivalent triggerPOST /api/vend HTTP/1.1
Host: api.interfile.co.za
Authorization: Bearer <lulamisapay_key>
Content-Type: application/json
{
"account": "9001234567",
"amount_cents": 60000,
"reference": "LP-TXN-abc123",
"service": "ELECTRICITY"
}
→ 200 OK
{
"token": "1234-5678-9012-3456",
"status": "VENDED",
"ref": "IF-20260610-99988"
}
Security & Compliance
Every layer — from the WhatsApp webhook to the database — is designed with South African regulatory requirements and OWASP security controls in mind. Below: the executive summary, the architecture, and the specific answer to every question a partner's security team asks.
LulamisaPay is built so that a failure in any single layer is contained by the next. Customer card details never touch our systems — they go straight from the customer's browser to the licensed payment provider. Personal data is AES-256 encrypted, so it is unreadable even if a database were ever copied. Our application runs with the minimum privilege it needs — it cannot be turned into a foothold on our servers or escalate inside the database. Every dependency and container image is cryptographically verified, and runtime monitoring flags anomalies within seconds. Partner funds, customer data, and platform integrity are protected by independent, defense-in-depth controls — not a single perimeter that fails all at once.
Traffic between customers, partners and us can't be intercepted, tampered with, or abused.
Only authentic, well-formed requests do anything — and money events can't be replayed or duplicated.
Even a bug in our own code can't be leveraged into control of the server.
no-new-privilegesThe application can only touch the data it needs — it can't escalate inside the database.
Sensitive data is unreadable at rest, and nothing unverified ever runs in production.
/.well-known/security.txt)The way a minor bug becomes a headline breach is escalation: code execution → server takeover → database superuser → data theft or crypto-mining. On LulamisaPay every step of that chain is independently blocked.
A flaw lands in the web tier — say a vulnerable dependency allowing code execution.
Can't take the host: non-root, read-only filesystem, all capabilities dropped, resources capped.
Can't escalate in the DB: the app's role is not a superuser — no new users, no OS-command execution, no schema changes.
Can't read the data: PII is AES-256 encrypted, so even a raw table dump is meaningless.
Can't stay hidden: runtime monitoring (Falco) and the database role-audit tripwire alert on anomalies within seconds.
Phone numbers and SA ID numbers are encrypted at column level using SQLAlchemy-utils StringEncryptedType. Encrypted columns remain equality-queryable.
Every new user must accept the POPIA notice before any PII is stored. Consent is recorded with a timestamp. No PII captured without explicit opt-in.
All inbound WhatsApp and BNPL webhooks are verified with HMAC-SHA256 signatures before any processing. Replays and spoofed calls are rejected.
A partial unique index on the ledger_entries table guarantees exactly one CHARGE per transaction. Duplicate PAID webhooks silently no-op — no double-billing possible.
Rolling 24h transaction count and value caps per account. New-account limits. Blocklist for confirmed fraudsters. All thresholds are admin-configurable without redeploying.
Transactions above a configurable threshold are held for manual review before the irreversible vend — preventing loss on card reversals that arrive after value is handed over.
Every transaction stage (created → paid → fulfilled) is logged to an append-only audit_logs table keyed by transaction UUID. Support can trace exactly where anything got stuck.
Redis-backed sliding-window rate limiting on all inbound webhook endpoints. Fails open (passes traffic) if Redis is down — service continuity over hard block.
Database schema is managed with Alembic version-controlled migrations. No manual SQL in production; every schema change is reviewed, tested, and reproducible.
Consent-gated PII, right-to-be-forgotten, data-processing agreements available.
Card data never touches us — it goes straight to the licensed payment provider.
Controls mapped to the OWASP Top 10 & ASVS; defense-in-depth by design.
RFC 9116 security.txt — a clear channel to report issues privately.
pip-audit), container images and infrastructure config (Trivy) for known vulnerabilities and misconfigurations, and a secret-scanner (gitleaks) blocks credentials from ever being committed. Scans also run on a weekly schedule to catch advisories published against versions we already run.security.txt so researchers and partners have a clear, private channel to report anything — and we act on it. We're glad to walk your security team through our architecture and share the relevant controls in detail under NDA.Getting Started
The typical partner goes from first API call to live production in four weeks. We handle all the complexity — you provide sandbox credentials and a test account.
Frequently Asked Concerns
Honest answers to the questions every potential partner has before signing.
What's Next
Where LulamisaPay is going — so you can plan your partnership accordingly.
Let's Talk
Whether you're a BNPL provider looking for a new essential-services segment, or a bill holder wanting guaranteed, instant payment — we'd love to walk you through a live demo.
Message us — we use the platform we're pitching
30-minute live walkthrough — end-to-end on a real WhatsApp number