The half of a store that quietly loses money
We are not a storefront-theming shop, and we will not pretend to be. What we do is the money path: gateway integration, checkout, subscriptions, discounts, renewals and refund reconciliation — built so a dropped connection cannot charge a customer twice or lose an order.
Storefronts are a solved problem. Payments are not
If you need a catalogue, a cart and a theme, an existing platform will serve you better and cheaper than any agency writing one from scratch. We would rather say that than sell you a rebuild you do not need.
What those platforms do not solve is the part specific to you: a custom checkout, a subscription or instalment model, a discount engine with real rules, reconciliation against your accounting, or a gateway that has no ready-made plugin for your stack.
That is also where the losses hide. A charge that succeeds while the response is lost, a webhook processed twice, a promo code that stacks in a way nobody intended, a renewal that silently stops — none of these announce themselves. They surface in a month-end that does not balance.
Where we are genuinely useful
Every item here is something we built and still run ourselves — not a service line we have only read about.
Gateway integration
Full server-side integration including the payment-intention flow, the signed hand-off to the provider's hosted checkout, and the webhook that settles it — not a copied snippet nobody on the team understands.
Charges that cannot double
Idempotency keys and claim-before-charge, so a retry after a lost response settles to one charge. This is the single most expensive bug in payments and it is preventable.
Webhooks reconciled
Signature verification, replay protection and an idempotent ledger, so a provider retrying the same event five times still produces exactly one order.
Subscriptions and renewals
Recurring billing with a real dunning state machine: pre-renewal reminders at seven, three and one day out, scheduled retries, a grace period before suspension, and cancellation that behaves the way the customer was told it would.
Promo codes with real rules
Eligibility, expiry, usage caps and per-customer limits — enforced on the server, where a determined customer cannot reach, so the price previewed at checkout is always the price charged.
Refunds and reversals reconciled
A refund or void raised with your provider — by webhook, or by someone clicking refund in their dashboard — is detected, applied to your own records, and reflected in the customer's access, so your ledger still matches the provider's when someone eventually asks.
Checkout that converts
Fewer fields, clear errors, the plan and the in-flight order preserved when a payment fails or the customer hits back, and a flow that works one-handed on a phone on mobile data.
Built for local buyers
Arabic checkout that reads naturally, local payment habits accommodated — cards and mobile wallets, not a European default — and the charged currency stated explicitly at every step rather than assumed.
How a payments build runs
The same sequence on every engagement, whatever the stack.
1. Map the money path
Every state an order can reach, including the ugly ones: charged but not recorded, recorded but not charged, refunded twice. Naming them is what makes them handleable.
2. Build against the failures
Implemented and tested against dropped responses, duplicate webhooks and retries — in a sandbox, before real money is involved.
3. Reconcile and hand over
Your ledger checked against the provider’s, alerts for anything that diverges, and a runbook for the cases that need a human.
Straight answers
The questions that actually come up on a first call.
Only when there is a real reason to. For an ordinary catalogue-and-cart store, an existing platform will beat a custom build on cost, time and risk, and we will say so. We come in for the custom part — checkout, subscriptions, a gateway with no plugin, or a discount and pricing model that no off-the-shelf product supports.
Paymob end to end, including the intention flow, webhook verification and exactly-once charging, running in production on our own product. The patterns are gateway-agnostic and we will integrate whichever suits your market and settlement terms.
Yes, and it is a good first engagement. We look for duplicate-charge exposure, unverified webhooks, race conditions on stock or promo codes, and gaps between your records and the provider’s. You get the findings as a document whether or not you hire us to fix them.
Sandbox credentials, automated tests covering the failure paths explicitly, and a controlled first run in production with small real amounts before switching over. We do not test a money path by hoping.
Something in your money path worth fixing?
Tell us what you are selling and how customers pay. You get back a map of your money path with the failure cases named, and a written estimate for closing them.
Every project starts with a scoping conversation and a written estimate before any code is written. No retainer required to talk.