Ecommerce
Ecommerce app and software development that still balances after a bad network day
Hashlogics is an ecommerce app development company that builds mobile commerce apps, marketplaces and retail software where a retried payment never charges twice and stock counts survive a race.
- 4.8 on Clutch across 22 reviews
- PremiumAudit.io: audit cycle cut 75%, calculation errors cut 95%
- In production for SmartREI, Tankaware, ZyloBase, KiwiWrite
Anybody can put a cart on a page. The work that decides whether your finance team trusts the system happens in the seconds after a customer's connection drops mid-payment. Did the charge land? Did the order get written twice? Does your stock count still match the shelf? Those questions have engineering answers, and they have to be built in before launch rather than patched in after the first bad month. That is the part we are hired for.
The double charge nobody can explain
A customer taps pay. The connection stalls. They tap again. Now your processor has two authorisations, your database has two orders, and your support inbox has one very annoyed person.
That retry was correct behaviour. Your system treated the second request as new information, and that is the bug. Stripe's own guidance is to retry a request whose result you never saw, using the same idempotency key. The platform then returns the original outcome instead of doing the work twice.
The same shape of failure hits inventory. Two customers buy the last unit within the same second. Both get a confirmation. One of them is going to get an apology email, and your stock figure was wrong from that moment onward.
When to build, and when to use a platform
Most stores should not be custom, and we will say so early. Selling physical products through a fairly standard flow? A hosted platform hands you a checkout that already survived millions of edge cases. You would otherwise meet those personally.
Custom earns its place when the commerce is unusual. Money held between two parties until work is done. Pricing that depends on a calculation rather than a table. Inventory that lives in somebody else's system. Subscriptions with rules your platform's billing cannot express.
If your answer is Shopify, our Shopify development page covers that work specifically, including where we extend a store rather than replace it.
- 01Standard catalogue, standard checkout: use a platform, and we will help you extend it.
- 02Money held, split or released against a milestone: that is custom, and it is where we are useful.
- 03Price computed per customer, per site or per contract: custom.
- 04Stock that lives in an ERP or a warehouse system: integration work, not a storefront project.
What is running now
Counted, not estimated
40+
published case studies of systems we built
7
payment and billing integrations across those builds
24h
window Stripe documents for retrying with the same idempotency key
255
character limit Stripe sets on an idempotency key
What we build into a commerce system
The storefront is the part you see. These are the parts that decide whether the numbers hold.
Idempotent writes on every payment and order path, so a retried request returns the first result instead of creating a second charge.
Money stored as integers in the smallest currency unit, because a float cannot hold ten pence exactly and the error compounds across a ledger.
Stock decrements that cannot be won twice, handled in the database rather than in application code that hopes for the best.
Webhook handling that assumes duplicates and out-of-order delivery, since every payment processor will send both eventually.
A reconciliation view that matches your orders against what the processor actually settled, so a mismatch is visible the next morning.
Refunds, partial refunds and disputes treated as first-class flows rather than something support does by hand in a dashboard.
What we will talk you out of
- A custom checkout, where a hosted one keeps you further away from card data and handles more edge cases than we could justify rebuilding.
- Replatforming before anyone has established which of your current problems are actually the platform's fault.
Ecommerce mobile apps your customers keep on their phone
An ecommerce mobile app earns its place when customers come back often: a membership, a repeat order, a marketplace. We build them in React Native with a cart that survives a dropped connection, Apple Pay and Google Pay through Stripe, push notifications tied to real events like a restock or a delivery, and a catalogue that still loads offline.
Offline, the restaurant membership app we helped build, now serves 15,000+ paying members across 11 US cities with 500+ restaurant partners. Event Snapshot lets guests scan a QR code, find their event photos, pay by card and download them on their own phone. If you're unsure you need an app at all, a fast mobile site often wins for one-off buyers, and we'll say which you are.
Retail and POS software: one stock count, in store and online
Retail software fails when the shop floor and the website keep separate stock. We build the layer that keeps one count: Square or your POS reporting every in-store sale, the online store reading the same number, and a reconciliation that flags drift the next morning. BrandLocator, the map-first store discovery app we built with its admin portal, shows how store, brand and offer data can stay managed in one place.
If you sell on Shopify, our Shopify development page covers apps and extensions, and Shopify vs custom ecommerce helps you decide. Payment work on its own lives on payment gateway integration, and why payments need an idempotency key explains the one rule every checkout needs.
- Reserve stockDecided in the database, not in a race.
- Take paymentIdempotency key on every attempt.
- Write the orderOnce, whatever the network did.
- Absorb webhooksDuplicates and out-of-order, expected.
- ReconcileYour ledger against the processor's.
- Handle the exceptionRefunds and disputes as real flows.
The fourth station is where most builds are optimistic. A processor may send the same event twice, and a handler that assumes exactly-once delivery will eventually ship the same order twice.
Holding money between two strangers
Marketplaces are where commerce gets genuinely difficult. The buyer has paid, the seller has not finished, and your platform is sitting on money that belongs to neither of them yet.
WorkMateAI is that shape. For Australia's on-demand trades marketplace we built hold-and-release payments on Stripe Connect. Around it sit provider verification, e-signed agreements and a dispute process that escalates in stages. Every dispute action is audit-logged, because the argument you cannot reconstruct is the one that costs you.
- Funds release against a defined event, not against somebody remembering.
- Every state change on an order is recorded, so a dispute is checked rather than argued.
- Legal documents are stored encrypted with retention rules written down.
- Admin actions are role-limited, because a support tool with full payment rights is a liability.
What we build on
Payments
- Stripe
- Stripe Connect
- Square
- PayPal
- Webhook verification
Build
- Next.js
- React
- TypeScript
- FastAPI
- Ruby on Rails
- PostgreSQL
- Supabase
Commerce integrations
- Shopify
- WordPress
- Wix
- Squarespace
- QuickBooks
- Mailchimp
Run
- AWS
- Vercel
- Docker
- Sentry
- GitHub Actions
Systems where money had to reconcile
Offline
Restaurant discovery people pay to keep.
Read the case study →
WorkMateAI
Disputes, payments, and compliance for Australia's on-demand trades.
Read the case study →
Event Snapshot
Guests buy their event photos before they leave.
Read the case study →
BrandLocator
Your favorite brands' stores, on one map.
Read the case study →
“I am extremely happy with the results and would highly recommend Hashlogics to anyone.”
Daniel Khin · CEO, PremiumAudit.io
The usual ecommerce build against ours
Both look the same on a good day. They separate on the day the network does not cooperate.
A retried payment
The usual approach
Two charges, and a support ticket.
How we build
Same idempotency key returns the first result.
Storing money
The usual approach
A float, because the column accepted it.
How we build
Integers in the smallest unit, so nothing drifts.
The last unit in stock
The usual approach
Two customers, one apology.
How we build
The database decides, and only one wins.
Duplicate webhooks
The usual approach
Processed twice, silently.
How we build
Expected, deduplicated, and safe to replay.
Finance asking about a gap
The usual approach
Someone exports two spreadsheets.
How we build
A reconciliation view built for exactly that question.
After launch
The usual approach
The contract ends at go-live.
How we build
An agreed service level, or a documented handover to your team.
Bring us the checkout you're not sure will hold
Scoping calls are free. Every build starts with a fixed-fee Blueprint: an engineer reads your real systems and writes the plan, with a fixed price for each milestone rather than a guess. The fee is credited in full against the build, and if the plan isn't one you'd act on, you don't pay for it.
01What does an ecommerce app development company build?+
An ecommerce app development company builds the apps and software that take orders and money: mobile commerce apps, marketplaces, checkout and payment flows, retail and POS software, and the reconciliation behind them. Hashlogics builds those so payments, stock and orders still agree after a failed request.
02Do I need an app or is a mobile site enough?+
A mobile site is enough when most buyers purchase once. An app pays off when customers return often, through a membership, repeat orders or a marketplace, because push notifications, saved payment and an offline catalogue keep them coming back.
03Can you build retail or POS software?+
Yes. We build retail software that keeps one stock count across the shop and the website, reading sales from Square or your POS and reconciling every morning. Where a packaged POS already works, we integrate with it rather than replace it.
04Do you build on Shopify or custom?+
Both. If your catalogue and checkout are standard, Shopify is usually right and our Shopify development work extends it. Custom wins when money is held or split, pricing is calculated, or stock lives in another system.
05How do you stop a customer being charged twice?+
Every payment request carries an idempotency key, so a retry returns the original result rather than starting a new charge. Stripe documents a 24-hour window for safely retrying with the same key. Reuse that key with different parameters and Stripe returns an error rather than a surprise. The application also has to be built so nothing downstream of the payment runs twice.
06Should we build custom or use Shopify?+
Use a platform unless your commerce is genuinely unusual, and we will tell you which you are in the first conversation. Held funds, computed pricing, external inventory and unusual subscription rules are the four reasons custom tends to win. Our Shopify page covers the extend-a-store route in detail.
07Can you work with the store we already run?+
Yes, and that is most of this work. Maidily connects to Stripe, Square, QuickBooks and storefronts on Shopify, WordPress, Wix and Squarespace. A cleaning company's site was never going to be rebuilt to suit us. Integration is usually cheaper and less disruptive than replacement.
08What about PCI compliance?+
We keep card data out of your systems wherever possible, which is the design decision that does most of the work. Using a hosted payment field means the card number never touches your server, and that changes which PCI questionnaire applies to you. We design to keep your scope as small as it can be, and document it for your assessor.
09Our stock counts drift. Is that fixable?+
Usually, and the cause is normally that two things can decrement stock at once without either knowing. The fix is making the database the arbiter rather than application code, plus a reconciliation job that compares system stock against reality on a schedule. Where stock lives in an ERP, the honest answer is that one system must own the truth and the other must follow.
10How do you handle refunds and disputes?+
As designed flows with their own states and their own audit trail, not as something support improvises in a processor dashboard. WorkMateAI escalates disputes in stages and logs every action taken. A dispute you cannot reconstruct six months later is the one that becomes expensive.
11We are a small brand. Is this overkill?+
The payment correctness work is not optional at any size, and it is cheap when built in and expensive when retrofitted. What scales down is scope: one clean checkout path and one reconciliation view beats a platform you will not use. Enterprise buyers get the same foundations plus access control, audit expectations and integration into finance systems.
12How much does an ecommerce app cost?+
The drivers are how many systems must agree about an order, whether money is held or split, and how unusual your pricing is. Scoping conversations cost nothing. The Blueprint is fixed-fee and credited in full against the build; if the plan isn't one you'd act on, you don't pay for it. The first 2 months of support and maintenance are free, with every build.
Related
- Shopify development →Extending a store rather than replacing it.
- Shopify vs custom ecommerce →Which one fits your store.
- Payment gateway integration →Stripe and Square, built to reconcile.
- Why you never use floats for money →The rounding bug that compounds across a ledger.
- Idempotency key →How a retried payment avoids a second charge.
- What PCI scope actually means →Which questionnaire applies, and why the answer changes.
- API integration →Connecting the store to the systems behind it.
