Taking payment for a WhatsApp shop in Zimbabwe and South Africa

A payment method has to answer four questions

Most advice about "getting paid online" starts with gateways and APIs. For a seller in Harare or Johannesburg the questions are much older than that:

• What does the buyer dial? *151# is not a link, and a ShapID is not a phone number.
• What does it cost them to move the money? That is the fee the buyer quietly pays, and in Zimbabwe it is two fees: the transfer and the IMTT.
• What proof does their app print? Some print a TxID, some print a reference, some print nothing you can find later.
• How do you match it to an order? Two people paying R120 on a Tuesday afternoon is the whole difficulty of a small shop.

A method that answers all four is usable. A method that answers three is a fight with your own memory.

What each method costs a small seller

These are the published tariffs this product models, checked against each provider's own pricing on 12 October 2026. They are the numbers a buyer pays to move money, not a platform's cut. Tariffs move with budgets and with exchange-rate policy, so treat them as a starting point and re-check twice a year.

The Zimbabwe detail foreigners get wrong

There is no "automatic" rail in Zimbabwe. Every method is a phone that a person looks at, which means the reconciliation is human, and the human is the shop owner at 20:40 with 30 unread chats. Two consequences worth designing around:

• Surcharging has to be computed, not toggled. "Pass the fee to the buyer" needs the transfer and the IMTT, or the shop eats 2% believing it charged 0%.
• A screenshot is not evidence. A "proof of payment" image in a market where the platform tells you to reconcile transfers yourself is the scam vector, not the defence.

How a payment finds its order in five seconds

Instead of asking the buyer what they paid and when, make the amount answer it. Take the order total and add a few odd cents, deterministically, so every order in the day has a different number:

The spread is under a rand, so it is not a charge — it is a fingerprint. It is also the reason a proof-of-payment picture stops being something you have to trust: you already know whose R120.43 that was. The companion guide goes into what to do on the rails where you still need a code — TxIDs, ShapIDs and references.

"Should I get a website?"

Not for payments. A website gives you a page to be found on and a form to lose money in; it does not give you a settlement. What a shop actually needs is four things, and none of them is hosting:

• a menu with prices that you can change without opening a spreadsheet;
• one place where the buyer sees the amount to send and the reference to quote;
• a list of orders that says which ones are paid, and which are a claim;
• a way for a stranger to find the shop without you messaging them.

The third is where shops bleed. A "paid" tick that anyone can tap is a refund you will eat; a paid tick that requires the money to have arrived is a record. If you use something that marks an order paid on request, the difference will show up as a monthly loss you cannot name.

What this costs, stated plainly

Tapstall is a storefront and an order ledger: your link is /s/yourshop, your buyers pay the methods above directly to you, and we are not in the money. The first 60 days are free. After that it is $60 USD for 365 days, one payment — not monthly billing, not a foreign card subscription, and no percentage of your orders. The fee calculator is public and needs no account; it also offers a January calendar reminder, because tariffs in this region change with budgets.

Set up is a store name, a menu and a PIN: /onboard. If you already keep a menu in a Google Sheet, point it at that; if you would rather not have a sheet at all, the shop's own menu editor is the authority and edits apply on save.