Services Portfolio About Process JournalContact Client login Start a project

What we build

The parts of a product that handle money.

Gateway integration, escrow and held funds, subscription billing, verification and onboarding, booking with deposits. Each one delivered as a defined piece of work: specified up front, built, handed over running in your own accounts.

FixedScope and price
1 dayTo a written scope
YoursAccounts and code
LiveEscrow in production

01

Payment gateway integration

Taking a card is the easy half. The half that goes wrong is everything around it.

The amount is decided on your server

Never sent up from the page. A basket arrives as ids and quantities and is priced against your own database immediately before the gateway is called, so a tampered request cannot change what is charged.

Paid means the provider said so

An order is marked paid after we call the gateway and it agrees on status, amount and currency — not because the browser reported success. A mismatch leaves it pending and flags it.

Webhooks that are actually verified

Signatures checked against the right secret, replays handled, and the same settlement path used whether confirmation arrives from the redirect or the webhook. The customer closing the tab does not lose the order.

Test credentials all the way through

You put a card through it yourself, in test mode, before it goes anywhere near a real one.

Worked with: Stripe, Paystack, PayFast. Others on request — the patterns transfer.

02

Escrow and held funds

The hardest thing on this page, and the one we can point at running.

Funds held until sign-off

A buyer pays, the money sits with a regulated escrow provider rather than with you, and it releases when the job is accepted. Neither side has to trust the other, which is the entire point of a marketplace.

The unhappy paths, specified

Disputes, partial releases, cancellations and refunds. These are most of the work and the reason escrow projects overrun when they are scoped as "add escrow".

Live, not theoretical

myQuack runs on TradeSafe escrow with verified providers and real payouts. It is ours, so you can be shown how it works rather than told.

See it running ↗

03

Subscription and recurring billing

Charging the card monthly is a weekend. Everything after the card fails is the project.

Plans, upgrades and proration

Moving between tiers mid-cycle without double-charging or giving a month away.

Dunning that is not just an email

Escalating reminders on a schedule, then a real consequence — suspension that actually suspends, and reinstatement the moment payment clears. A failed payment with no enforcement is a discount.

Cancellation that closes the loop

End of period, not end of sentence. The service comes down when it should, the customer is told, and resubscribing restores what they had.

04

Verification and onboarding

Getting someone from signed up to allowed to trade, without collecting more than you should.

Identity and company checks

Individuals and registered entities, checked against the appropriate registry, with a state machine that survives someone abandoning it halfway.

Documents handled properly

Data minimisation as a design choice: extract what is needed, discard the rest, and enforce retention with a scheduled purge rather than a promise in a policy. Built against POPIA; the same shape satisfies GDPR.

Secrets stored like secrets

Anything that can move money is encrypted at rest, and never rendered back to a screen in full.

05

Booking with deposits

For businesses where an empty slot is money already lost.

A slot held against a real payment

Availability, double-booking prevention, and a deposit taken at the moment of booking rather than chased afterwards.

Cancellation rules written down

What is refundable, until when, and what happens on a no-show — decided up front and enforced by the system, so it never becomes a conversation.

How it runs

Scope, build, hand over.

Three steps, and the first one is where the risk actually lives.

01

Scope it

A call, then a written specification: what gets built, what does not, what we need from you, the price and the date. If the scope is wrong we find out here rather than in week three.
02

Build it

You get something you can open and click, not a status report. Test credentials throughout.
03

Hand it over

Live, in your accounts, on your infrastructure, documented. You own it outright and you deal with the person who built it.

Boundaries

What we will not take on

Said here so neither of us wastes a call finding out.

Open-ended retainers

We sell a finished piece of work, not hours. If you need another pair of hands on the team indefinitely, we are the wrong shop and will say so.

Rescuing an unfamiliar codebase against a deadline

Inheriting a system nobody can explain and debugging it to a date is how projects fail. We would rather decline than take it and disappoint you.

Work with no written scope

If it cannot be specified it cannot be priced, and neither of us would know what finished looks like.

FAQ

Straight answers

Which gateways do you work with?

Stripe, Paystack and PayFast in production. The patterns transfer to most providers, and the integration work is largely the same shape regardless of whose API is at the other end.

Do you work with clients outside South Africa?

Yes. The work is remote and the company invoices from South Africa.

Can you integrate into our existing product?

Usually, if the payment flow can be specified as a defined piece of work against a codebase we can read. If it turns into open-ended maintenance of an unfamiliar system, we will tell you that instead of quoting.

Who owns the finished system?

You do, outright. It runs in your own gateway and hosting accounts, and it is documented at handover.

Next step

Tell us what you need built

Describe the piece of work. You will get a written scope and a fixed price within one working day, or a straight answer that it is not for us.