Client / Sector
Thiqaty — digital escrow, fintech
Market
Algeria, consumer and merchant transactions
Engagement
Product strategy, brand and UI, web engineering, payments integration
Status
Live since 2025, shipping continuously
The situation
Most commerce in Algeria still closes on trust that has no infrastructure behind it. A seller posts on Ouedkniss or in a Facebook group, a buyer sends a CCP or BaridiMob transfer, and the only evidence either side holds is a photograph of a receipt in a private message. Cash on delivery covers the physical goods case and nothing else: it cannot cover a freelance contract delivered over three weeks, a service rendered in another wilaya, or a deal between two people who will never meet.
The gap is not payment. Cards work: CIB and Edahabia settle through the national scheme, and transfers clear fine. The gap is the window between paying and receiving, which in a low-trust market is exactly where deals die. Sellers refuse to ship first, buyers refuse to pay first, and the deal collapses into a negotiation about who is more likely to be a fraudster. International escrow is not an option — the platforms that solve this elsewhere do not onboard Algerian merchants and do not touch Algerian rails.
Thiqaty was built to be that window as a product: money enters custody, the work happens, and funds release only when both sides say the promise was kept. We designed and engineered it end to end — the escrow model, the money pipeline, the local payment integrations, the brand, the marketing surface and the admin console the operators run it from.
What made this hard
Trust had to be engineered, not claimed
The person we were designing for has already been scammed, probably more than once, and is being asked to hand money to a website instead of to a human. Every state a transaction can be in had to be explainable in a single sentence, in the user's own language, at the moment they are looking at it. A lifecycle that is correct but opaque is functionally the same as no escrow at all.
Four payment rails, two of them human
Card payments settle themselves; CCP and BaridiMob arrive as a photograph of a bank receipt that a person has to look at. Both had to land in the same ledger, produce the same balance and be reconcilable against the same transaction history. The hard part is that the manual path must never become the soft spot: the place where an operator's click can create money that no rail ever moved.
Money that has to move backwards without killing the deal
Escrow refunds are not order cancellations. A buyer may want one milestone back on a five-milestone contract and then carry on with the same seller. Our first model treated a full refund as terminal, which stranded partially funded deals in a state nobody could revive, and we had to rebuild the behaviour around the idea that a refund is an event inside a live escrow, not the end of one.
The counterparty is a stranger, not a colleague
Email invitations assume you already know who you are dealing with and that they check email. Real sellers post a link in a comment, a story or a WhatsApp broadcast and let whoever wants it come. Onboarding a second party had to work for a person who arrives cold from a public link, with no account, and joins the transaction in the same motion as signing in.
A pricing model that cannot punish the user
Fee-free transaction packs are only useful if running out of quota does not stop a deal. Blocking a transaction because a subscription lapsed would break the exact promise the product exists to make. The commercial model had to degrade gracefully instead of failing closed, which pushed the complexity into disclosure rather than enforcement.
How we approached it
We treated Thiqaty as a money system with a marketing site attached, not a marketplace with a payment button. That ordering decided the architecture: a domain-driven backend where escrow, deposits, refunds and subscriptions are separate bounded concerns over one relational database, and a product surface that never invents its own truth about a balance.
The design work ran in parallel and answered a narrower question: what does a person need to see, in Arabic, French or English, to believe their money is safe right now. Everything else — the marketplace, the share links, the packs, the blog — was built on top of a lifecycle we could state plainly before we drew a single screen.
The escrow model and the trust language
We fixed the transaction lifecycle first: the states an escrow can occupy, who can move it between them, and what each state means for the money. Milestones came out of this phase — funding a contract in parts is the difference between escrow being usable for freelance work and being usable only for parcels. The brand and interface language were designed against those states, so the visual system had something real to explain.
Wallets, deposits and the ledger
Every movement of money in the platform became a ledger entry paired to a balance change, written inside a single database transaction. Deposits were modelled as one pipeline with a discriminator rather than a separate flow per payment method, so the wallet, the escrow funding and later the subscription purchases all reconcile against the same history and the same admin screen.
The local payment rails
We integrated card payment for CIB and Edahabia through the national gateway, alongside the manual CCP and BaridiMob path where a customer uploads a receipt and an operator approves it. This phase produced the branded A4 payment receipt, the emailed confirmation, the bot check in front of the payment step and the localised, code-free decline messages that replace raw gateway errors.
Getting the second party in
We added public transaction links in two shapes: a single-use link that brings one stranger into one specific escrow, and a reusable link that mints a fresh escrow between the seller and every distinct person who opens it. Both had to survive a sign-in redirect without losing the intent to join, and both had to stay out of the public marketplace listings unless the seller chose otherwise.
Monetisation, refunds and money-safety review
The last phase added fee-free transaction packs with admin-managed billing periods, then milestone-based refunds into the wallet. Both went through adversarial money review before deployment: every state transition that credits or debits was made idempotent and guarded, so a duplicated gateway callback or a double approval moves money exactly once or not at all.
What we shipped
Escrow core
- Milestone-based funding for contracts delivered in stages
- Full lifecycle: pending acceptance, accepted, completed, disputed, cancelled
- Two-sided release — funds move only when both parties confirm
- Dispute flow with operator arbitration in the admin console
- Public marketplace listings for sellers who want discovery
- Party-scoped transaction references so each side gets its own clean URL
Money and payments
- Wallet balances backed by a paired transaction ledger
- CIB and Edahabia card deposits through the national gateway
- CCP and BaridiMob deposits by receipt upload with operator approval
- Branded A4 PDF receipt, downloadable and emailable
- Milestone refunds credited back to the buyer's wallet
- Human-readable decline reasons in three languages instead of gateway codes
Distribution and commercial model
- Single-use join links for one named counterparty
- Reusable payment-style links that clone a new escrow per joiner
- Unlisted visibility, distinct from public marketplace listing
- Fee-free transaction packs with a monthly count and a per-transaction ceiling
- Globally managed billing periods, priced per plan and per period
- Live fee disclosure inside the creation flow, before anyone commits
Platform and operations
- Trilingual product in English, French and Arabic, RTL included
- Google sign-in and email one-time codes alongside session auth
- Operator console for deposits, refunds, disputes, plans and users
- Withdrawal-gated identity verification that does not block joining or funding
- Trilingual editorial blog with per-language URLs, hreflang and sitemap
- Bot verification in front of the card payment step
Engineering decisions
The choices that shaped the build, and what each one traded away.
Refunds are quantised to milestones, never to a typed amount
A free-form refund amount lets the sum of funded milestones drift away from the amount held, and once that invariant breaks, reconciliation becomes guesswork and the platform can be drained a few dinars at a time. We removed the free-form path entirely: a buyer selects whole funded milestones, and the amount is always their sum. The trade-off is real: a buyer cannot claw back part of a milestone, so milestones have to be sized thoughtfully when the escrow is created, and we had to make that sizing step feel natural rather than bureaucratic.
A refund does not terminate the escrow
Our first design flipped a fully refunded escrow to a terminal refunded state. It was clean on paper and wrong in practice: partially funded deals ended up frozen with no way for either party to revive them. Now an approved refund unfunds the affected milestones, reduces the held amount and leaves the escrow active, so the buyer can re-fund and carry on or cancel deliberately. The cost is that status alone no longer tells you whether money moved back, which forced us to surface refund history as a first-class panel on the transaction rather than as an audit-log footnote.
One deposit pipeline with a discriminator, not a pipeline per product
Wallet top-ups, escrow funding and subscription purchases all enter as deposits carrying a field that says what completing them should do — credit a balance, fund a milestone, or activate a plan. One pipeline means one reconciliation surface, one operator approval screen and one place where completion logic lives. The discipline it demands is parity: the platform has an automatic entry point and a manual receipt entry point, and any new field has to be threaded through both. We learned that the hard way and now treat it as a review checklist item, because a field dropped on one path is a payment that does the wrong thing.
Payment acknowledgement is classified from authoritative fields only
The moment a card payment is acknowledged is the money event, and acknowledgement payloads are not uniform — optional descriptive fields can be absent on a perfectly approved transaction. A classifier that demands an optional field will reject good money and tell a customer who genuinely paid that they did not. We defined success from the fields the gateway guarantees, treated the rest as guards applied only when present, extracted the classifier as a pure function and covered it with a unit-test suite that gates the build. Completion is then applied through a conditional state transition, so a duplicated callback or a race between an automatic and a manual path credits exactly once. Fewer defensive checks in the happy path is the trade-off; the tests are what make it safe.
Cookie locale for the app, URL locale for the blog
The authenticated product picks its language from a preference cookie, which keeps one URL per page and suits a signed-in app. Search engines cannot index three languages behind one URL, so the blog — and only the blog — was given URL-scoped locale routing with canonical tags, hreflang alternates and a sitemap covering every language variant, with the language switcher taught to rewrite the URL segment there instead of just re-rendering. The trade-off is two locale mechanisms in one codebase and a document language attribute that follows the cookie rather than the URL. Moving the entire application to URL locales would fix the inconsistency; it would also be a rewrite of every route, so we documented it instead of pretending it away.
The outcome
Thiqaty runs as a working escrow platform: transactions are created, funded through cards or bank transfer receipts, delivered against milestones and released on two-sided confirmation, with disputes and refunds handled by operators inside the admin console rather than in a comment thread. The money surface is the part we are most confident about — every credit and debit is a ledger entry, every completion is idempotent, and the operators can trace any balance back to the rail it came from.
The commercial layer shipped in stages and now supports fee-free transaction packs sold across admin-defined billing periods, purchasable from wallet balance, by card, or by uploading a transfer receipt for approval. Because overage never blocks a transaction, the pricing model behaves like a discount rather than a gate: a user who exceeds their quota sees the standard fee explained in the creation flow, with the upgrade path next to it.
Around the product, the trilingual editorial blog gives the brand a public surface that can actually be found in Arabic, French and English — a small piece of engineering with a disproportionate effect for a company whose entire proposition is that strangers should trust it before they have used it.
3
Transaction types
Goods, services and freelance contracts each carry their own escrow flow and release conditions.
4
Local payment rails
CIB and Edahabia cards, plus CCP and BaridiMob transfers settled from an uploaded receipt.
3
Interface languages
English, French and Arabic across the whole product, with the Arabic surface laid out right to left.
12 wks
To first production release
From product model to a live platform accepting real deposits; the roadmap has kept shipping since.
Honestly
The manual rails are still manual, and that is a deliberate constraint rather than an oversight. CCP and BaridiMob deposits depend on a person reading a receipt, which means the platform's settlement speed on those rails is a staffing question, not an engineering one. We built the tooling to make that review fast and auditable, but we did not pretend software could remove the human from a rail that has no programmatic confirmation.
The same honesty applies to the parts we chose not to build. Subscriptions do not auto-renew; a lapsed plan quietly reverts to the standard fee rather than charging a stored card, because in this market a surprise debit costs more trust than it earns revenue. And the locale split between the app and the blog is a known inconsistency we can live with today and will have to resolve if the marketing surface grows beyond the blog. Money systems reward being explicit about what you have not solved.
Frequently asked
How does an escrow platform actually work for online sales in Algeria?
The buyer funds the transaction into custody instead of paying the seller directly. The seller ships or delivers, and the funds are released only when both parties confirm the promise was kept. If the deal is delivered in stages, the money is held and released milestone by milestone, and a dispute pauses release until an operator arbitrates.
Can a fintech product accept CIB and Edahabia card payments online?
Yes, through the national card gateway, and Thiqaty does. The work is less about the API than about correctness at the acknowledgement step, where a payment either becomes money or does not. We also kept CCP and BaridiMob available as a receipt-upload path, because a meaningful share of Algerian customers still prefer a transfer to a card.
What happens if a buyer wants a refund halfway through a contract?
On Thiqaty a refund is milestone-based and does not end the transaction. The buyer requests specific funded milestones back, an operator approves, the amount is credited to their wallet and the escrow stays active — so they can re-fund and continue with the same seller, or cancel separately. The platform fee is not refunded; the principal is.
How long does it take to build a payments or escrow product from scratch?
Thiqaty reached its first production release in about twelve weeks, covering the escrow model, wallets and ledger, the local payment rails and the operator console. Everything since — public transaction links, subscription packs, milestone refunds, the trilingual blog — has been shipped incrementally on top of that base, which is the pattern we recommend for any money system.