Case Study
Mohiya
A storefront where browsing, cart, and checkout hang together, with a payment gateway wired in so a purchase is verified from first click to paid.
My Role
Developer on the project team, owning the shopping and payment flow.
Tech Stack
Mohiya is a foundation in Bali that makes and sells printed tote bags. Every sale needs the same handful of things: what was ordered, who ordered it, where it goes, whether it has been paid, and where the parcel has got to.
The foundation wanted to sell directly rather than take orders one message at a time, which meant a storefront where a customer can go from browsing to paid without anyone in the middle.
I worked as a developer on the project team and owned the shopping and payment flow: the storefront, the cart, the checkout, and everything that happens after someone pays.
The problem
- There was no way to buy directly. Orders arrived as messages, and every one of them had to be handled by hand.
- Payment had to be confirmed manually. Someone had to check a transfer had actually landed before an order could move.
- The customer could not see their own order. Once they had paid, the only way to find out what was happening was to ask.
- Nothing tied the steps together. Browsing, ordering, paying and shipping were separate conversations rather than one flow.
What I built
A storefront you can actually browse
The landing page opens with the bags being used rather than a grid of products, then drops straight into the first row of what is for sale. The catalogue behind it is the whole range, named and priced.
A product page that gets out of the way
Photo, price, description, quantity. Two buttons: add to cart, or buy it now. Recommendations sit underneath, because someone buying one bag is often buying more than one.
Adding to the cart confirms in place rather than throwing you onto another page. If you are still shopping, you should still be on the shop.
A cart that stays editable
Quantities can be changed right up to checkout, with the subtotal following along. Nobody should have to start over because they wanted two instead of one.
Checkout, paid through Midtrans
Shipping details on one side, payment methods on the other, and the order summary updating beside both. I integrated Midtrans so the customer can pay by bank transfer or card without leaving the page.
The important part is behind it. The order is only marked paid when Midtrans confirms it to the server, not when the browser says the payment went through. A browser can be wrong, or lied to.
And then a tracker, so nobody has to ask
After paying, the customer gets a payment code and a progress tracker that follows the order from awaiting payment through to completion, with the full breakdown underneath.
The result
- A customer goes from the landing page to a paid order without anyone handling it in between.
- Payment is verified server side against Midtrans, so an order is only paid when the gateway says it is.
- The buyer can see where their order is instead of messaging to find out.
- Orders arrive as records rather than as chat messages someone has to transcribe.
Built with Laravel and MySQL, with Midtrans handling payments.