The product thesis
Make everyday acceptance and settlement part of a connected business journey.
The strategy linked merchant onboarding, payment acceptance, supplier collection, spending control and banking services. Its value depended on those activities working together: a merchant needed to accept payment, understand available funds and use those funds in the next business transaction.
For corporates, the proposition extended from collecting money to controlling outgoing spend and understanding activity across channels. Consumer concepts added spending visibility, recurring commitments and payment choice. This provided a broader product direction while keeping the initial delivery anchored in merchant and corporate use cases.
| Stakeholder | Need expressed in the strategy | Product response | Intended value |
|---|---|---|---|
| Merchant | Start accepting payments and access funds quickly | Onboarding, digital account, payment acceptance and settlement visibility | Faster first use and more useful working capital |
| Corporate | Collect and manage money across a distributed business | Digital invoicing, collection, spend control and reporting | Less manual coordination and clearer financial control |
| Consumer | Manage spending and upcoming commitments | Family spend controls, payment planning and payment options | Clearer everyday financial decisions |
| Bank | Extend digital services and business insight | Managed payment capabilities, account activity and analytics | More efficient service delivery and deeper customer usage |
Stakeholder needs come from the strategy materials. They are not presented as interview findings.
Product strategy and stakeholder proposition
Choices that shape the product
The journeys embody decisions about speed, support and control.
These choices are visible in the project flows and functional use cases. The rationale is a product interpretation of those artifacts, rather than a claim that a formal options-scoring exercise was conducted.
| Design choice | Behavior specified | Reason it matters | Trade-off to manage |
|---|---|---|---|
| Self-service and assisted onboarding | Merchants can proceed themselves, use tutorials or seek sales support | Accommodates different levels of digital confidence | Keep the same status and required information across paths |
| Limited activation before full activation | Initial use precedes the final operations approval | Separates time to first value from full account readiness | Make available services and restrictions understandable |
| OCR with manual completion | Captured documents can populate fields; missing data can be entered | Reduces repeated typing without depending entirely on automation | Require a review step and useful fallback guidance |
| Multiple supplier payment options | A payment plan can use supported account and cash methods | Reflects how merchants actually fund business payments | Confirm balance, authorization and any cash handoff |
| Recurring invoice lifecycle | Review and confirmation precede scheduled sending | Makes ongoing collection manageable | Handle edits, reminders and rejected requests deliberately |
Onboarding, invoice and payment flows
Onboarding as a service
Registration is only the beginning of becoming ready to transact.
This is where product management and service design meet. The customer-facing path depends on frontline support, operations review and coordinated account status. A successful screen sequence must therefore agree with the service that staff can deliver.
Register and verify
Capture the initial details and verify the mobile channel.
Output: Verified entry into the onboarding journey
Choose the support path
Offer self onboarding, tutorials or sales assistance.
Output: A route appropriate to the merchant’s needs
Capture and review documents
Support camera or attachment, OCR where available and manual completion where needed.
Output: Reviewable registration information
Show activation progress
Explain the transition from partial availability to full readiness and communicate status changes.
Output: A merchant who knows what is available and what remains
Support stalled journeys
The service flow includes follow-up when a registrant does not continue.
Output: A recovery path beyond an abandoned form
Merchant registration and onboarding flow
Scope before expansion
The historical plan put acceptance and business payments ahead of wider consumer services.
The first product emphasis was a viable merchant and corporate acceptance ecosystem. The documented scope included onboarding, account maintenance, payment acceptance, supplier invoices, cash-in and cash-out, notifications and operational inquiry. Later offering phases introduced broader issued-card and consumer-wallet capabilities, transfers, merchant bill payment and additional services.
The technology implementation also had its own sequence, with processing capabilities, certifications and later migration work. The product offering roadmap and the platform implementation roadmap should be read as two related planning views.
| Planning layer | Initial focus | Later expansion | Dependency |
|---|---|---|---|
| Business offering | Merchant and corporate acceptance; supplier payments and collection | Consumer wallets, transfers and merchant value-added services | Account readiness, scheme capability and stakeholder agreement |
| Merchant experience | Register, activate, receive payments, manage account and supplier obligations | Broader payment choices and additional services | Clear activation status and supported payment methods |
| Platform delivery | Foundational account and processing capabilities | Further certifications, integrations and migration work | Test readiness, external systems and formal acceptance |
This is a documented historical sequence, not proof that every planned feature shipped. No prioritization scores have been reconstructed.
Historical offering and implementation plans
From journeys to a testable backlog
Requirement quality appears in the conditions for completion and recovery.
These are representative requirement examples reconstructed from the supplied flows and use cases. They show how an epic becomes concrete: actor, trigger, state change, completion evidence and exception path. They are not a reproduced Jira export.
Backlog, sprint and release ownership required keeping those conditions aligned across customer experience and delivery. The implementation materials explicitly call for requirements to be complete, consistent and testable before development proceeds.
| Representative backlog item | Successful behavior | Exception or control |
|---|---|---|
| Complete merchant onboarding | The merchant receives the applicable activation status and next action | Rejected information can be corrected and submitted again |
| Accept a terminal assignment | A merchant confirms receipt and the required activation details | A rejected assignment returns for correction |
| Pay a supplier invoice | The payment plan is reviewed and executed; final status is communicated | Insufficient balance requires a revised plan |
| Send and track an invoice | Review, sharing and recipient payment lead to a receipt | Unpaid and rejected invoices have reminder or resend paths |
| Complete a QR transaction | Confirmation leads to a scan and an intelligible receipt | A transaction can time out or be cancelled; recovery is explicit |
| Withdraw to a bank account | A selected bank account, amount and confirmation lead to a receipt | Bank details and the withdrawal summary are reviewable before completion |
Product flows and delivery requirements
Delivery across stakeholders
A payment experience relies on decisions made beyond the app.
The delivery specification separates integration testing, user acceptance and go-live decisions. Its change process asks for impact on scope, schedule, budget and quality before a change is authorized, rejected or deferred. This is the governance around release planning; it is not evidence that every gate passed.
| Stakeholder group | Contribution to delivery | Evidence needed at the handoff |
|---|---|---|
| Merchant and frontline sales | Registration information, assisted onboarding and device handoff | Reviewed information and confirmed customer acceptance |
| Business operations | Activation, exceptions and account decisions | Decision, status and clear reason when action is required |
| Bank and payment partners | Supported schemes, account functions and external services | Confirmed capabilities and agreed dependencies |
| Product and development | Functional behavior, business rules and implementation | Baselined requirements and traceable delivery scope |
| Testing and release owners | Integration testing, business acceptance and release readiness | Executed cases, defect decisions and acceptance sign-off |
Align the scope
Review requirements, dependencies, responsibilities and phase constraints.
Output: An agreed delivery baseline
Make requirements testable
Connect business behavior to integration and acceptance cases.
Output: Traceable completion criteria
Resolve delivery risk
Track defects, external readiness and changes to scope or schedule.
Output: A reviewable readiness decision
Approve and hand over
Complete business acceptance, release approval and support handover.
Output: A supported service transition
Implementation governance and acceptance approach
Designing the transaction around certainty
Invoices and QR payments show the product at its most consequential moments.
The invoice flow covers more than creation. It includes review, channel sharing, scheduled recurrence, recipient payment, receipts, unpaid reminders and rejected-state recovery. The product therefore supports both sides of a collection relationship.
The QR flow makes amount, fees, tax and total part of confirmation, then distinguishes a scanned transaction from a timeout or cancellation. Its receipt includes a transaction reference, time and success indication. Those details let a merchant understand what happened and take the next action.
Consumer mockups explore the same need for certainty through visible balances, an upcoming installment and a comparison of full payment with installment terms. They are concept UI with sample values.
- State what is happening before asking for confirmation.
- Show a clear result after the transaction.
- Keep reminders and recovery inside the service journey.
- Present payment options in terms the customer can compare.
Invoice and QR flows; consumer payment concepts
Measurement tied to the product promise
Measure movement through the service, alongside the business activity it enables.
| Question | Proposed measure | Why it matters |
|---|---|---|
| Can merchants reach first value? | Time from registration to first successful transaction | Tests the promise of faster onboarding |
| Does onboarding remain understandable? | Completion rate and abandonment by step and support path | Identifies friction and support demand |
| Does initial activation lead to readiness? | Progression from partial to full activation | Exposes unresolved review or status problems |
| Does digital collection reduce uncertainty? | Invoice payment cycle time, overdue rate and reminder-to-payment conversion | Links the flow to collection effectiveness |
| Can users recover from failure? | Timeout, rejection and retry rates; successful recovery | Tests the designed exception paths |
| Does the ecosystem become useful repeatedly? | Active merchants, repeat transaction use and use of linked business services | Connects experience quality to sustained product value |
This measurement plan is proposed from the documented product goals. The project materials do not establish baseline or post-launch results.
Product goals and proposed measurement
What the artifacts make clear
The strongest lesson is that product scope, service behavior and operating control must agree.
Fast onboarding needs more than fewer fields. It requires a coherent activation model, dependable approval handoffs and visible customer status. Likewise, settlement and payment confidence depend on consistent transaction capture and reconciliation beyond the visible interface.
The designs also show where complexity should be conditional: assistance for merchants who need it, manual fallback when document recognition fails, approval controls where roles require them, and recovery when an invoice or QR transaction does not complete. These are principles surfaced by the artifacts.
| Risk | Product response or release question |
|---|---|
| External capability or certification is late | Tie the release scope to confirmed partner readiness |
| Customer and operations see different status | Define one state model and notifications at each transition |
| Controls create unnecessary steps | Check which roles and authorizations are needed for the actual merchant setup |
| A successful payment is hard to verify | Provide receipts, transaction status and reconciliation evidence |
| A roadmap becomes an implied delivery promise | Separate planned capabilities from accepted and released scope |
Service flows and delivery constraints
People and needs
Working archetypes, reconstructed from project context. They are not a separate validated research sample.
Merchant owner
- Goal
- Begin accepting payments and understand activation.
- Friction
- Different levels of digital confidence and incomplete onboarding.
- Experience need
- Assisted or self-service paths, OCR fallback and visible status.
Corporate finance team
- Goal
- Manage invoicing and collections.
- Friction
- Manual tracking and uncertainty about invoice status.
- Experience need
- Sharing, reminders, receipts and rejection recovery.
Consumer
- Goal
- Manage funds and upcoming commitments.
- Friction
- Comparing payment options and understanding monthly obligations.
- Experience need
- Balance visibility, payment choices and term comparison.
Key screens & project artifacts
Outcomes and learning
Payment products launched in the first year
B2B customers acquired in the first two months
Partner groups: banks, platforms, merchants and corporates
The launch and customer figures come from my career record. The merchant interface demonstrates design scope; it should not be interpreted as proof that every screen shown was released. Product results reflect cross-functional and partner delivery.
The product is the experience, the business model and the partner system working together.
About the evidence
- Source evidence includes historical strategy, stakeholder propositions, product flows and delivery specifications. Public copy summarizes mechanisms rather than reproducing sensitive commercial or technical detail.
- Planned roadmap items, concept UI and proposed measures are distinguished from verified outcomes.
- Career record: personal product ownership and reported first-year launches/customer acquisition.
