LojaMi — Digital Transaction Ecosystem for Timor-Leste

A connected digital commerce ecosystem consisting of LojaMi Agente, LojaMi Amigu, and LojaMi Sales—supporting digital product purchases, agent operations, customer rewards, field distribution, and financial transactions across Timor-Leste.

Overview

LojaMi is a connected digital transaction and commerce ecosystem designed for customers, merchants, agents, and field sales teams in Timor-Leste.

Rather than operating as a single application, LojaMi connects three mobile products with different responsibilities:

LojaMi Agente — supports merchants and agents in selling digital products, managing balances, earning commissions, and serving customer transactions
LojaMi Amigu — provides customers with digital transactions, voucher redemption, points, rewards, missions, transfers, top-ups, and withdrawals
LojaMi Sales — supports field sales operations, agent balance distribution, voucher inventory, and sales reporting

Together, these applications form an operational ecosystem where sales teams distribute value to agents, agents serve customers, and customers receive digital products and rewards through connected transaction flows.

Official Website: lojami.tl
Google Play Developer Page: Ekosistem Pasar Digital

The Ecosystem

LojaMi Agente

LojaMi Agente is designed for merchants and authorized agents who provide digital products and financial services to customers.

The application supports activities such as:

mobile credit and data package purchases
EDTL electricity token purchases and bill payments
game voucher transactions
single and bulk voucher injection
customer top-up and withdrawal services
transfers between LojaMi users and supported banks
QR-based payment requests
transaction and voucher tracking
main balance, commission, and reward-point monitoring

For agents, the application acts as both a transaction tool and a business management interface. Each successful flow must correctly update balances, commissions, points, receipts, and transaction history.

LojaMi Amigu

LojaMi Amigu is the customer-facing application within the ecosystem.

It allows users to:

redeem digital vouchers through authorized agents
purchase mobile credit, electricity tokens, and game products
transfer balances between LojaMi accounts
top up and withdraw funds through nearby agents
earn LojaPoint from eligible transactions
complete missions and redeem available rewards
review transaction history and account activity

The application combines everyday digital transactions with a lightweight reward system, giving users additional value through points, missions, and promotional opportunities.

LojaMi Sales

LojaMi Sales is an internal application for field sales operations.

Its primary functions include:

registering and authenticating sales personnel
managing sales balances
topping up agent balances during field visits
distributing empty voucher inventory
submitting sales reports with supporting photos
reviewing previously submitted reports
exporting transaction records

This application connects operational field activities with the wider LojaMi transaction ecosystem and helps maintain the availability of agent balances and voucher inventory.

My Contribution

Role: Quality Assurance Engineer
Focus Area: Mobile applications, CMS, API responses, and financial transaction validation

My responsibility was to validate that the connected LojaMi ecosystem behaved consistently across user roles, applications, services, and transaction records.

The work covered both staging and production validation, with particular attention to transaction accuracy and user-visible financial information.

Testing Scope

End-to-End Transaction Testing

I tested core transaction flows across Agente, Amigu, and Sales, including:

Sales to Agente balance top-up
Amigu top-up through Agente
Amigu withdrawal through Agente
Amigu-to-Amigu balance transfer
Agente-to-Agente balance transfer
static QR payments
dynamic QR payments
EDTL inquiry and payment
mobile credit and data-package purchases
game voucher purchases
voucher injection and redemption
refund-related transaction behavior
settlement and fee-settlement records

Each scenario was verified beyond the success message shown by the application. The validation also covered the resulting balances, ledger entries, commissions, points, receipts, transaction history, and CMS records.

Financial Reconciliation

Transaction testing required comparing values across multiple sources.

For each relevant scenario, I validated:

product price displayed before payment
amount shown on the confirmation page
opening and closing main balance
actual balance deduction
expected and actual commission
expected and actual LojaPoint
receipt details
mobile transaction history
API response data
CMS settlement records
transaction reference numbers
transaction status and timestamps

This reconciliation process helped identify issues that could not be detected by checking the application interface alone.

Transaction History and Settlement Validation

I validated whether transaction records remained consistent across the mobile applications and CMS.

The checks included:

settlement and fee-settlement entries
debit and credit directions
reference numbers and transaction identifiers
transaction status consistency
pagination and infinite-scroll behavior
history completeness after refresh or relogin
UTC, local-time, and Dili-time presentation
Excel and PDF export results
exported data compared with filtered CMS results

This was especially important because a transaction could appear successful to the user while still producing an incorrect balance, incomplete history, or inconsistent backend record.

Key Issues Investigated

During testing and release validation, I investigated issues such as:

balance deductions greater than the displayed product price
commissions not being credited after successful transactions
commissions being credited with an incorrect value
duplicated commission or reward-point updates
LojaPoint increasing again after refresh or relogin
different product prices appearing across catalog, confirmation, receipt, history, API, and CMS
incomplete transaction history caused by pagination or loading behavior
transaction export results not matching CMS filters or UI data
refund history not showing complete information
incorrect EDTL meter validation on the first attempt
transaction timestamps differing between mobile, CMS, UTC, and Dili local time
OTP rate limits not matching the expected requirement
inquiry or payment failures returned by external wallet and gateway services
duplicate transaction responses and inconsistent error handling
receipt, reference number, serial number, and biller-information inconsistencies

The objective was not only to report visible bugs, but to determine whether an issue originated from the mobile interface, transaction service, gateway, settlement process, or data presentation layer.

Testing Approach

Structured Manual Scenarios

Test scenarios were documented with:

preconditions
test data and transaction amount
execution steps
expected result
actual result
supporting screenshots or recordings
Pass, Fail, or Blocked status
notes for developers and stakeholders

The scenarios were kept practical and focused on real operational behavior rather than unnecessary test-case volume.

Regression and Release Validation

After fixes or new releases, affected flows were tested again to verify that:

the original issue had been resolved
related transaction flows still worked
balances and commissions remained accurate
no new inconsistency appeared in the history or CMS
production behavior matched the validated staging result

Production validation used controlled transaction amounts to reduce operational risk while still confirming real behavior.

Network and Response-Time Validation

Selected EDTL and transaction scenarios were also tested under constrained network conditions using combinations such as mobile network throttling and VPN connections.

The purpose was to observe:

inquiry response time
payment-processing time
status-check behavior
timeout handling
loading-state behavior
duplicate-action risk during slow responses

This helped validate not only whether a transaction succeeded, but also whether the user experience remained understandable during delayed processing.

QA Deliverables

My QA outputs included:

structured manual test scenarios
release and regression validation reports
financial reconciliation tables
transaction evidence and supporting screenshots
concise ClickUp tickets for developer review
production validation summaries
stakeholder updates for WhatsApp and internal communication
clear separation between confirmed issues, warnings, blocked scenarios, and cases that could not be reproduced

Reports were written to be direct and actionable, with enough context for developers to investigate without overstating the severity of an unconfirmed issue.

Key Outcomes

Improved visibility into balance, commission, point, and settlement inconsistencies
Stronger validation across mobile applications, APIs, and CMS records
More reliable regression checks for financial transaction flows
Clearer developer communication supported by reproducible evidence
Better confidence when validating releases in staging and production
A reusable transaction-testing approach for multiple products and user roles

Official Application Screenshots

The following images are loaded directly from the official Google Play listing. No local image files are required.

LojaMi Agente

LojaMi Amigu

LojaMi Sales

Application Icons

Platform Structure (At a Glance)

Mobile applications for Agente, Amigu, and Sales
CMS for transaction and operational monitoring
API-based transaction processing
External biller, wallet, banking, and digital-product integrations
Balance, commission, reward-point, and settlement records
Transaction history and export functionality
Multilingual user experience for the Timor-Leste market

(Internal architecture and implementation details are intentionally kept high-level.)

Notes

This project is presented as a quality assurance and transaction-system case study.

Sensitive information—including personal data, account identifiers, phone numbers, internal configurations, production credentials, and complete transaction references—is not disclosed.

The focus is on:

ecosystem understanding
transaction-flow validation
financial reconciliation
issue investigation
release confidence
collaboration between QA, developers, and product stakeholders

One-Line Summary

A connected digital transaction ecosystem for Timor-Leste, validated end-to-end across customers, agents, field sales, mobile applications, APIs, and operational records.