Overview
GPay Credit Log is a speculative feature exploring how Google Pay could better support everyday credit transactions commonly used by small neighborhood shops. The intent was to bridge the gap between digital payments and the informal, trust-based credit systems that merchants already rely on, without disrupting existing behavior.
I designed a native credit ledger within Google Pay focused on speed, visibility, and ease of adoption. The scope intentionally excludes lending, underwriting, and manual settlement to stay aligned with behavioral realities and regulatory boundaries. Instead, the feature strengthens everyday transactions, improves merchant retention, increases engagement, and differentiates Google Pay by supporting real-world commerce patterns that existing digital tools overlook.
Note: UPI is a real-time payment system and does not support informal or unregulated credit transactions. This project focuses on credit tracking rather than credit issuance.
Problem
While using UPI apps for digital payments on a daily basis, I noticed a clear gap between how payments work today and how everyday credit continues to function in neighbourhood shops. Although UPI has digitised the moment of payment, the informal credit system (udhaar) that supports many households still lives offline, in notebooks, loose papers, and memory.
What stood out was that this gap was not caused by a lack of technology or unwillingness to adopt digital tools. Most shopkeepers already use UPI apps like Google Pay multiple times a day. The real issue is that existing payment apps do not support this informal but critical part of their daily workflow.
As a result, shopkeepers are forced to switch between a digital payment app and a manual credit system, leading to friction, calculation errors, missed entries, and avoidable disputes. Customers, on the other hand, have little visibility into what they owe until a disagreement arises.
The problem I set out to solve was how to make credit tracking clear, shared, and dependable without disrupting the trust-based behaviour that already works for both shopkeepers and customers.
How might Google Pay help shopkeepers and customers manage everyday credit transparently within the app they already use?
Success Criteria & Constraints
Before moving into design, I defined what success would look like for this feature and the constraints it needed to operate within. This helped me stay focused on solving the right problem rather than over-designing the solution.
Success Criteria
I considered the feature successful if it could:
- Reduce reliance on physical notebooks for credit tracking
- Make outstanding credit visible and understandable to both shopkeepers and customers
- Fit naturally into existing Google Pay usage without requiring extra setup or learning
- Encourage regular use for a daily or weekly activity
- Support smooth and dispute-free end-of-month settlement
From a product perspective, this would translate into higher merchant engagement, increased daily usage, and stronger retention among small businesses.
Constraints
While defining the solution, I was mindful of several real-world constraints:
- Credit is built on trust and routine; changing how it works would risk adoption.
- Many shopkeepers are not tech-savvy and avoid exploring settings or new features.
- Shops operate in busy, low-attention environments where speed matters.
- Errors or misuse could directly impact financial relationships.
- UPI regulations restrict informal credit, requiring the feature to function as record-keeping rather than a payment mechanism.
Acknowledging these constraints helped me prioritise simplicity, familiarity, and clarity over advanced functionality.
Research Approach
Since this was a self-initiated project, I used lightweight, contextual research methods to understand real behaviour without disrupting daily routines. The goal wasn’t statistical validation, but identifying consistent patterns in how shopkeepers and customers manage credit today.
I began with direct observation at neighbourhood stores, watching how credit was recorded during both busy and quieter periods. This helped me understand the pace, constraints, and shortcuts shopkeepers rely on.
I complemented this with informal conversations with shopkeepers and regular customers during transactions. Keeping these discussions short and natural made participants more comfortable and candid. I focused on how credit is tracked, where issues arise, and how settlements typically happen.
In parallel, I reviewed existing Google Pay merchant and payment flows to understand where a credit-tracking feature could integrate naturally, and where added complexity would break existing mental models.
While the research sample was small and geographically limited, it was sufficient to validate the problem, uncover repeatable patterns, and inform early product and design decisions.
Key Insights
From my observations and conversations, a few consistent insights emerged. These directly shaped how I framed the problem and designed the solution.
Speed matters more than features
Recording credit is a quick, habitual action. During peak hours, shopkeepers don’t want extra steps or screens.
Design implication: The feature had to be fast, visible by default, and usable with minimal interaction.
Familiarity drives adoption
Even when digital options exist, shopkeepers rely on notebooks because they’re familiar and predictable. The barrier isn’t technology, it’s comfort.
Design implication: The solution needed to reuse existing Google Pay patterns instead of introducing new workflows or terminology.
Customers need visibility, not control
Customers generally trust shopkeepers but struggle to remember amounts or verify totals later.
Design implication: Shared visibility and real-time confirmation mattered more than advanced controls or dispute mechanisms.
No appetite for another app
Most shopkeepers and customers were strongly against using a separate app just to manage credit.
Design implication: The solution had to live natively inside Google Pay and integrate with existing payment flows.
Manual calculation is unavoidable
Shopkeepers almost always total multiple items before recording a single credit entry.
Design implication: A built-in calculator was essential to support real-world behaviour.
Trust needs structure, not enforcement
Participants were more concerned about clarity and reliable records than strict controls.
Design implication: Transparent logs, timestamps, and notifications build trust more effectively than rigid confirmation or restriction mechanisms.
Personas
Based on my research, I identified two primary user groups who interact with the credit system in very different ways. Defining these personas helped me balance speed, trust, and visibility across both sides of the interaction.
Current User Journeys
To clearly understand where things break today, I mapped the existing credit journey from both the shopkeeper’s and the customer’s perspectives. This helped me identify friction points, moments of uncertainty, and opportunities where digital support could add real value.
Solution Overview
Based on the insights, journeys, and principles defined earlier, I designed GPay Credit Log as a lightweight, integrated feature that helps shopkeepers and customers manage everyday credit directly within Google Pay.
At its core, GPay Credit Log functions as a digital credit ledger. It allows shopkeepers to record credit entries for regular customers, while enabling customers to view, track, and settle those credits transparently. The feature fits naturally into existing Google Pay flows, ensuring it feels familiar rather than disruptive.
For shopkeepers, the feature replaces handwritten notebooks with a simple and reliable way to log credit, calculate totals, and view outstanding balances per customer. For customers, it provides clear visibility into how much they owe, access to past credit entries, and a straightforward path to settle dues using UPI.
Just as importantly, I was deliberate about what this solution does not attempt to be. GPay Credit Log does not issue credit, enforce repayment, or alter the trust-based nature of the shopkeeper–customer relationship. It focuses purely on tracking, visibility, and settlement, staying aligned with real-world behaviour and platform constraints.
By digitising credit tracking without changing how credit itself works, the solution bridges the gap between modern digital payments and a deeply rooted offline practice, while strengthening Google Pay’s role in everyday commerce.
Feature Scope & Requirements
To keep the solution focused and usable, I defined a clear feature scope early on. This helped prioritise what was essential for solving the core problem while avoiding complexity that could hinder adoption.
In Scope
Merchant-side capabilities
- Add credit entries directly within Google Pay
- Select customers using recent contacts or UPI ID
- Enter amounts quickly with a built-in calculator
- View customer-wise credit history and running balance
- See a consolidated list of customers with outstanding credit
- Send reminders for pending dues
- Access clear monthly summaries
Customer-side capabilities
- View shops where they have outstanding credit
- Receive real-time updates for new credit entries
- Access transparent credit history with timestamps
- View total outstanding balance
- Settle dues seamlessly via existing UPI flows
System-level requirements
- Native integration within Google Pay
- Shared visibility for both parties
- Clear audit trail for transparency and trust
- Reliable performance in low-connectivity environments
- Secure handling of sensitive financial data
Out of Scope (Intentionally Deferred)
To maintain simplicity and reduce risk, the following were deliberately excluded from the initial version.
- Issuing or underwriting credit
- Manual marking of credit as settled without payment
- Credit limits or deposits
- Customer-side credit creation or editing
These features introduce additional complexity, trust considerations, and regulatory implications, and are better treated as potential future enhancements.
Information Architecture
Once the feature scope was clear, I mapped out the information architecture to ensure GPay Credit Log fit naturally into Google Pay’s existing structure. The goal was to make the feature easy to access for those who need it, without adding clutter or forcing new navigation patterns.
For merchants, credit management is an active and frequent task. I placed Credit Log within areas they already associate with business activity, ensuring it felt like a natural extension of their daily workflow.
For customers, credit visibility is more passive but still important. Their information architecture surfaces outstanding credit clearly, without demanding attention unless action is required.
Key User Flows
To ensure the feature worked smoothly in real-world conditions, I focused on a small set of critical user flows that cover the most frequent and high-impact actions. These flows were designed to be fast, predictable, and consistent with existing Google Pay behaviour.
Wireframes
Before moving into visual design, I created low-fidelity wireframes to validate structure, hierarchy, and core interactions. At this stage, the focus was on ensuring the feature fit naturally within Google Pay’s existing flows and supported real-world usage without unnecessary complexity.
Mockups with Design Rationale
Merchant View
Home Screen
Decision
I placed the Credit Book card directly below the “Payments” and “Money
Received” sections, aligned with Google Pay’s existing Home screen.
Rationale
This mirrors how shopkeepers typically review daily activity—checking
recent transactions first, followed by outstanding dues. Showing
customers with profile images enables quick recognition, and since
most shops manage fewer than ~20 regular creditors, this preview
remains readable without clutter.
Credit Log – Expanded View
Decision
I surfaced the total outstanding credit prominently at the top,
followed by a clear “Add New Tab” action and a simple list of customers
with amounts owed.
Rationale
The total outstanding amount is the most important metric for
shopkeepers. Placing it upfront allows for quick assessment, while the
list view supports at-a-glance scanning without deeper navigation.
Customer Credit Detail Screen
Decision
I modelled this screen closely on the existing Payment Profile UI, with
actions to add entries and send reminders.
Rationale
Reusing familiar patterns reduces the learning curve and aligns with
real-world behaviour, where shopkeepers record entries, review history,
and occasionally nudge customers for settlement—all from one place.
Add Credit Entry Screen
Decision
I designed the entry screen to match Google Pay’s payment amount
interface and integrated an optional in-app calculator.
Rationale
Shopkeepers often total multiple items before recording credit.
Embedding the calculator avoids app switching and supports faster,
more accurate entry. Returning users directly to the customer’s credit
detail screen keeps the flow predictable and efficient.
Mockups with Design Rationale
Customer View
Home Screen
Decision
I placed the Credit Log between the “People” and “Bills & Recharges”
sections on the Home screen.
Rationale
Money transfers to friends and family happen most frequently, while
bill payments are typically monthly. Shop credit sits in between—used
daily or a few times a week. This placement keeps Credit Log easy to
access without competing with high-frequency actions users rely on
most.
Expanded Credit List Screen
Decision
I designed this screen as a compact list of shops where the customer
has outstanding credit, showing the shop name, amount due, new entry
status, and the total credit across all shops.
Rationale
Most customers maintain credit with only one to three shops, and
rarely more than five. A simple list view provides immediate clarity
without overwhelming the user or requiring additional navigation.
Credit Profile Screen
Decision
I modelled this screen on Google Pay’s existing Payment Profile layout
and limited actions to viewing entries and settling dues.
Rationale
In real life, credit is recorded by the shopkeeper, not the customer.
Restricting control to the merchant side preserves this dynamic while
giving customers visibility and a clear path to settlement. Reusing
familiar patterns keeps the experience low-effort and easy to
understand.
Testing & Learnings
Testing this solution was more challenging than expected. While customers were comfortable reviewing designs, shopkeepers were initially hesitant, often feeling that they were being tested rather than the product. To adapt, I walked them through the screens and asked how they would perform each action, which helped them feel more at ease while still validating the flows.
Familiarity reduced hesitation
Users responded more positively to screens that felt immediately familiar, even before fully understanding the feature.
Speed outweighed feature depth
Shopkeepers consistently focused on how quickly they could add a credit entry, especially during busy hours.
Customers wanted clearer monthly summaries
Reviewing a full month’s purchases required scrolling through individual entries. A consolidated monthly view would make settlement easier.
Key Trade-offs & Decisions
Default visibility vs. optional activation
I debated whether Credit Log should be visible by default or enabled manually through Quick Links. While optional activation seemed logical since not all merchants offer credit, testing with traditional shopkeepers showed that many wouldn’t explore settings to enable it, even if it solved a real problem.
Making Credit Log visible by default increases adoption for users who need it most. To balance this, I validated the approach with larger merchants who don’t offer credit, and most were comfortable hiding the feature once they understood its purpose.
On the customer side, I kept the feature hidden by default. Since credit is merchant-initiated and not relevant to everyone, a subtle banner or contextual prompt felt more appropriate than permanent visibility.
Localisation over clever terminology
Many shopkeepers used Google Pay in their local language, reinforcing the need for simple, everyday terms. Literal or overly clever translations often don’t match common usage and can slow adoption.
I intentionally used straightforward language across the UI so the feature could be localised accurately without losing clarity or meaning.
Automatic settlement vs. manual control
Although many credit settlements still happen offline, giving merchants the ability to manually mark credits as settled introduced unnecessary risks such as accidental settlements, partial payments, and inconsistent records.
For the initial version, I tied settlement directly to digital payments to keep the system predictable and reliable. Manual or partial settlement is better suited as a future enhancement once users are comfortable with the workflow.
Why these decisions matter
Across these trade-offs, a clear pattern emerged: clarity and predictability mattered more than flexibility. Prioritising simplicity helped reduce errors, build trust, and keep the feature approachable for first-time users.
User Impact (Observed)
While this was a speculative feature, I walked through the concept and flows with both shopkeepers and customers to understand how well it aligned with their existing habits.
“As long as it doesn’t increase my effort, I can see myself using it.”
Shopkeepers related to the idea of a shared credit log within Google Pay, mainly because it mirrored how they already track credit today, just without notebooks. They found value in having entries recorded in one place, as long as it didn’t slow them down or require additional steps during busy hours.
“It’s better to see it myself than be reminded later, especially in front of others.”
Customers responded positively to having clear visibility into their outstanding credit without needing to ask or rely on memory. For many, the ability to quietly track dues reduced awkward conversations and made settlement feel more predictable and less uncomfortable.
Across these conversations, the feature was understood quickly by both groups, suggesting that the approach fit naturally with existing mental models and everyday behaviour rather than introducing a new system to learn.
Future Opportunities
While the initial version of GPay Credit Log focuses on simplicity and adoption, the feature opens up several opportunities for thoughtful evolution as merchants and customers grow more comfortable with digital credit tracking.
Customer Confirmation & Safeguards
Some customers expressed concerns around incorrect or accidental credit entries. In the future, lightweight safeguards such as optional customer confirmation or proximity-based validation could help build confidence, especially in environments where trust is still forming.
Partial and Offline Settlements
Many credit settlements still happen in cash. Once users are familiar with the core workflow, the feature could support partial payments or manual settlement markers, designed carefully to avoid confusion and maintain record integrity.
Insights for Merchants
Over time, aggregated credit data could offer shopkeepers simple insights such as frequently delayed payments or monthly trends, helping them manage credit more confidently without turning the feature into a complex accounting tool.
Scalable Merchant Services
As Credit Log becomes part of daily operations, it could serve as a foundation for broader merchant-facing capabilities within Google Pay, while remaining aligned with platform and regulatory constraints.
The intent behind these future opportunities is not to replace trust with control, but to strengthen it with clarity. By evolving gradually and responsibly, GPay Credit Log can continue to support real-world behaviour while expanding value for both users and the business.
What I’d Explore Further With More Time & Resources
Deeper validation through real usage
With more time, I would validate the concept in a live or semi-live environment by observing real credit entries over an extended period. This would help surface behavioural shifts such as forgotten entries, delayed settlements, and changes in trust dynamics that short-term walkthroughs can’t fully reveal.
Stress-testing edge cases and breakdown moments
I would spend more time testing failure scenarios such as incorrect entries, disputes, or situations where trust breaks down between shopkeepers and customers. These moments are where credit systems are most fragile, and understanding user reactions here would be critical before expanding functionality.
Exploring merchant segmentation
While this project focused on neighbourhood shops, I would explore how credit behaviour differs across merchant types such as pharmacies, hardware stores, or service-based businesses. This would help identify where the feature creates the most value and how workflows might need to adapt across contexts.
Defining and measuring meaningful success metrics
Finally, I would define and track clear success metrics such as active shop and customer usage, frequency of credit entries, repeat usage per customer, and settlement completion rates. These indicators would help validate whether the feature becomes part of daily behaviour rather than a one-time utility.
Final Reflection
Working on GPay Credit Log reinforced my belief that impactful product ideas often come from observing what people already do, rather than imagining entirely new behaviours. This project pushed me to balance empathy with restraint—resisting the urge to overbuild and instead focusing on clarity, trust, and adoption.
It also helped me sharpen my product judgement. I learned to define scope deliberately, work within regulatory and behavioural constraints, and make trade-offs that favour simplicity over flexibility. Most importantly, it reminded me that good product design isn’t about replacing existing systems, but strengthening them in ways that feel natural and reliable.