TechTur Solutions logo
TechTurSolutions
How We Launched a Fashion Brand Online Before It Had a Payment Gateway
All Articles
E-CommerceNext.jsTypeScriptPrismaDeployment

How We Launched a Fashion Brand Online Before It Had a Payment Gateway

Ngano Dzedu had a collection, a name and a story — but no merchant account, no final prices and no product photography. Here is how we built a real online store around what the business actually had, and made switching everything on later a matter of changing one line.

14 September 20265 min read1 views
Share

Most online-store projects start with the payment gateway and work outwards. This one could not. When Ngano Dzedu came to us, the brand was ready — the collection was designed, the name carried meaning, the visual direction was settled. What was not ready was almost everything a conventional e-commerce build quietly assumes: no merchant account, no confirmed retail prices, no finalised size chart, and no product photography beyond the brand boards themselves.

The standard advice in that situation is to wait. We think that advice costs small businesses months they cannot afford.

Why "wait until you're ready" is the expensive option

A brand that is invisible while it gets ready is still paying for the wait — in momentum, in the customers who found a competitor instead, in a launch that lands to an audience of nobody. Meanwhile the things being waited for are often circular: you want good photography before you launch, but the photography budget depends on sales.

So the question we asked was not "how do we build the store she will need in six months?" It was "what is the smallest honest version of this shop that can trade tomorrow, and how do we make sure it grows into the full thing without a rebuild?"

Selling by conversation, not by checkout

In Zimbabwe, a great deal of commerce already happens on WhatsApp. That is not a workaround — for a considered purchase like modest fashion, where sizing is a conversation and trust matters more than convenience, it is genuinely how the market prefers to buy.

So the shop launched in what we call enquiry-only mode. Customers browse a real storefront, build a real basket, and place a real order — the order is recorded properly in the database with line items, sizes, colours and totals. What it does not do is take a card. Instead it hands off to WhatsApp with the whole order already written into the message, and the owner records the payment in her admin when the money arrives by EcoCash, transfer or cash.

The important detail is that this is not a fake checkout. Every order is a first-class record. The dashboard totals are real. When online payment is switched on, nothing about how orders are stored has to change.

Designing for the switch, not for the state

The part worth stealing from this build is the way anything unavailable at launch was put behind an interface rather than hard-coded around.

Payments and file storage both sit behind small driver registries. Storage writes to the server's own disk today; when the brand has a Cloudinary or S3 account, that becomes one environment variable and every existing upload keeps working. Payments has Paynow, Stripe and PayPal implementations already written and inert — each one refuses to enable itself until its credentials exist, and says so in the boot log rather than failing silently at checkout.

  • Nothing half-configured can switch itself on by accident.
  • Nothing needs rewriting when the credentials arrive.
  • The business can go live now and upgrade on its own timetable.

We also built a sandbox payment gateway that implements the same interface as the real ones and moves no money, so the entire path — checkout, payment page, confirmation, receipt email — could be rehearsed and proven before a single real credential existed.

Selling something that has not been made yet

Ngano Dzedu's pieces are made to order, with lead times of three weeks or so. A normal "add to basket, pay, ship" flow describes none of that.

So products carry a sale mode rather than a simple in-stock flag. A piece can be in stock, or made to order with a deposit taken up front and the balance due before dispatch, and the product page, the basket and the order record all behave differently depending on which. The deposit logic lives in the order model, not in the payment provider — which is why it works identically whether the owner is recording EcoCash payments by hand today or running a card gateway tomorrow.

The honesty problem — and the feature it produced

This is the decision we are most pleased with.

The brand boards included colourways that were beautiful but not confirmed for production. Putting them in the shop as buyable products would have been a small lie that turns into a real problem the moment somebody orders one.

Leaving them out entirely would have been a waste — they were some of the strongest imagery the brand had, and the interest they generate is genuinely useful market research.

So we built a third state: the piece is displayed in full, clearly marked as a concept, and cannot be added to a basket at all. Instead it invites the visitor to register interest.

The brand gets to show its best work, the customer is never misled, and the owner gets a list of exactly who wants the navy version — which is a far better basis for deciding what to produce next than a guess.

The receipt is part of the brand too

When money does arrive, the customer gets a receipt built from the same template whether it reaches them by email or by WhatsApp — the same figures, the same wording, the brand's own typography and colours rather than a default system message. A deposit reads differently from a payment in full, and it tells the customer what happens next instead of just confirming a number.

It is a small thing that most stores get wrong, and it is often the only piece of written communication a customer keeps.

If your business is in the same position

Plenty of good businesses are sitting on a launch because one piece of infrastructure is missing — a merchant account, a photographer, a final price list. Usually that is not a reason to wait. It is a reason to build the thing so that the missing piece is a switch rather than a rebuild.

That is most of what we do at TechTur Solutions: work out what the business can honestly offer today, build that properly, and make sure the version it grows into does not mean starting again.

You can see the result at nganodzedu.techtursolutions.com. If you are somewhere similar and want to talk it through, get in touch — the first conversation is free, and often the most useful part is simply working out what you actually need first.

Found this helpful?

Share
More Articles

Enjoyed this article?

Get more design tips and web dev insights in your inbox. No spam — just good content.