Building YukStay's payment system from scratch

Context

YukStay is a property technology company focused on co-living, working with offline agents to rent and manage units. Tenants paid rent, and that is where operations were quietly leaking.

Before this project there was no payment system. There was a manual transfer, and a WhatsApp message with a photo of the receipt sent to an agent, who forwarded it to the ops team. Billing was assembled by hand. Management decided to build something more automated — a business-driven project aimed at saving operational cost, with the hope that it would also make paying easier for tenants.

Role and team

I was a UI/UX designer on this project; design was a team of 2. I worked on both ends of the system — the user-facing payment flow in the tenant app and the admin-side billing the ops team lived in.

The stakeholder group was the actual difficulty of the project: the ops team, who owned the internal tools; the finance team, whose data had to sync to their finance tools; the agent team, previously the direct connection collecting tenants’ payments; engineering; and design. We partnered with Stripe as the payment gateway — Stripe’s first project in Indonesia, so there was no local precedent for either company to copy.

The problem

The manual process was long, resource-hungry and prone to miscommunication, and it put a burden on agents who were not there to be a payment desk.

The cost was not one dramatic failure, it was a stack of small ones: every payment needed a human to receive a screenshot, verify it against a contract and record it; every contract needed a human to work out what was owed and when; and the people doing that work were ops and agents whose real job was elsewhere. Adding tenants meant adding that work.

Constraints

• No local precedent. Stripe had not run a project in Indonesia before, so integration questions had no reference implementation to work from.
• Requirements from three sides that did not agree. A tenant’s contract determines when the first payment is due. Ops and finance each had a different requirement for how the monthly due date should be specified, and both had to be satisfied by one system.
• Bills arrive on different dates. Monthly rent, maintenance and electricity are billed separately, with different due dates. They had to be presented and payable without turning into three separate chores.
• Most tenants paid manually. More than 80% of tenants used manual transfer before this. Any automated system had to still accommodate them rather than lock them out.

What I did

I started by getting the requirements out of each team rather than designing to a brief, then aligning a single solution across them and checking technical feasibility for the MVP. The work was as much facilitation as interface design: ops wanted control, finance wanted clean data in their tools, agents wanted to stop being the payment channel, and engineering wanted a scope that could ship.

On the design side:

• Bills are generated automatically on the admin side by reading the tenant’s contract date, amount and range, which removed the manual assembly step.
• The tenant app lets a tenant choose which bills to pay and shows the total, so rent, maintenance and electricity can be settled together rather than chased one by one.
• Payment completes through Stripe — debit or credit card, or a BCA virtual account — and is automatically confirmed and synced to Xero and the admin app.
• Manual transfer remained supported for the tenants still using it: the payment is uploaded by the tenant and confirmed by the finance team, with the same invoice record behind it.

For testing, we ran internal tests repeatedly to make sure the team could navigate every piece of functionality and adjusted from the feedback. On the tenant side, Stripe integration meant we could not test with just anyone, so we tested with internal users who also rent in our units. That surfaced problems with partial payments, which we adjusted before continuing.

Key decisions and trade-offs

We treated the finance requirements as equal to the operations requirements. The quickest route to an MVP would have been to build what ops needed and reconcile finance’s data by hand afterwards, recreating the manual load we were removing, just in a different team. Aligning both parties on due dates and bill structure cost us scope and time.

We kept manual transfer in the system instead of migrating everyone. A cleaner product would have retired the manual path at launch. With more than 80% of tenants paying that way, that would have meant an all-or-nothing rollout. We carried the weight of two payment paths to avoid a cliff.

We shipped manual-upload billing before Stripe, with the same invoice model underneath. Rather than wait for the Stripe integration, we made the admin invoice the source of truth from the start. That let the ops side start working immediately and kept Stripe as a payment-method change rather than a redesign.

We scoped to MVP and did not chase the full billing model. Contract-level cases — when the first payment is due, how due dates are specified, how a mid-contract change is billed — have a long tail. We handled the cases the current tenant base actually had and deliberately left the rest.

Outcome

There is no business outcome to report here, and none is claimed. The system reached MVP with Stripe integrated, bills generating automatically from contracts, and payment confirmed and synced to Xero and the admin app. Going from a receipt screenshot in a WhatsApp thread to an automated billing and payment flow was the deliverable, and it shipped.

I am not going to dress that up. This was a systems and cross-functional alignment project that got to a working first version, and the interesting part was never the checkout screen.

What I’d do differently

I would have run the usability test with real tenants rather than internal users who rent in our units. It was the pragmatic choice, since Stripe integration was required to use the flow at all, but it was a biased sample — those people already knew our admin staff and could work around gaps a stranger would have hit. Partial payments were exactly the kind of case an outsider would have found faster.

I would also have defined how the split billing would look to tenants before building the admin side. We designed the admin invoice model first, because that was where the manual pain was worst, then had to work out how to present three bills with three due dates in a way a tenant could act on. That translation cost more than it should have, and I could have made the call in the same meeting where the due-date requirements were agreed.

The third thing is smaller and more annoying in hindsight: we involved the agent team only after the shape of the solution existed, because they no longer owned the money. They had been explaining payment to tenants for months, and the objections they raised about partial payments and manual transfer should have been available to us at the start.