Fintech · Payments · SaaS
Newton
Payments
Designing B2B and B2C checkout workflows on payment gateway for a 50,000-user school management platform. Two completely different problems, one shared infrastructure.
- Role
- Product Manager
- Platform
- Web + Mobile
- Integration
- payment gateway
- Scale
- 50K+ users · 30–50 schools
4
Distinct payment flows designed end-to-end: parent fees, transport & activity bookings, staff salary, vendor payments
B2C + B2B payment surfaces
50K+
Users across multiple roles transacting through Newton's payment infrastructure daily
Parents · Staff · Finance teams · Admins
Real-time
Transaction reporting delivered to finance and operations teams across all B2B and B2C payment streams simultaneously
Multi-stream financial reporting
Schools collect money from many people, in many ways
Newton Classroom was already the operating system for 30–50 schools. But money, one of the most critical and sensitive parts of running an institution, was still being collected manually, tracked in spreadsheets, and reconciled by hand at month end.
B2C · Parent-facing
Parents pay the school
Term fees · Transport bookings · Food subscriptions · Activity registrations · Late fees · Instalment plans
B2B · Institutional
The school pays its people
Staff salary disbursements · Vendor invoices · Operational payments · Partnership billing · Payroll runs
Ops · Finance team
Finance needs to see everything
Real-time collection dashboards · Reconciliation reports · Defaulter tracking · Audit trails · Multi-school consolidation
The core tension
"B2C and B2B payment flows look similar on the surface, both move money through payment gateway. But the UX requirements, trust signals, error handling, and reporting logic are entirely different. Building one system to serve both without conflating them was the central product challenge."
What was breaking before the integration
Before Newton Payments, each school managed collections through a patchwork of bank transfers, cash receipts, WhatsApp reminders, and offline fee registers. Reconciliation was a monthly ordeal. Defaulters were tracked by memory.
On the B2B side, staff salaries and vendor payments were processed outside the system entirely, through manual bank uploads, paper approval chains, and disconnected accounting software.
Finance teams had no single view of money in and money out. Principals couldn't answer basic questions like "how much have we collected this term?" without a spreadsheet audit.
- ✕Manual fee collection with no digital trail, cash, cheques, and bank transfers tracked in registers
- ✕No parent-facing payment interface, every transaction required school office intervention
- ✕Staff salary processing done via manual bank uploads, outside the platform entirely
- ✕Vendor and supplier payments required paper approval chains with no audit log
- ✕Finance teams had zero real-time visibility, reconciliation was a monthly retrospective
- ✕Defaulter tracking relied on human memory and manual follow-up calls
- ✕No multi-school consolidated view for groups managing several institutions
Why B2C and B2B checkout needed separate product thinking
The naive approach would have been one payment flow with conditional logic. The right approach was recognising these are fundamentally different products sharing one integration layer.
| Dimension | B2C — Parent checkout | B2B — Institutional payments |
|---|---|---|
| Who is paying | Individual parent, often on mobile, varying digital literacy | School accountant or finance manager on desktop |
| What triggers payment | Term fee invoice, transport booking, activity sign-up | Salary run, vendor invoice, partnership agreement |
| Trust requirements | High. Parents need clarity on what they're paying and to whom. Anxious about overcharging. | Moderate. Institutional payer. Needs accurate amount and audit trail, less emotional friction. |
| Payment methods | UPI, cards, net banking, EMI / instalment plans | NEFT, RTGS, bulk payroll uploads, direct bank transfer |
| Error handling | Friendly, reassuring messaging. 'Your payment is safe.' Retry flows. | Precise, clinical. Amount, reference ID, bank response code. |
| Reporting output | Receipt PDF for parent. Collection entry for school finance. | Payroll register. Vendor payment confirmation. Ledger entry. |
| Compliance | PCI-DSS via payment gateway. Refund policy disclosure. | Salary compliance, TDS, vendor agreements, bank confirmation letters. |
What I owned end-to-end
Discovery
Payment workflow research
Ran discovery sessions with school finance teams, accountants, and parents to map existing payment behaviours, friction points, and trust requirements for each flow before a single spec was written.
Product spec
Payment gateway integration requirements
Translated finance workflows into precise product specifications for engineering, payment API sync validation, webhook handling, refund flows, and checkout UX for B2C and B2B separately.
Execution
Cross-functional delivery
Drove end-to-end integration with engineering, from Payment gateway API spec review to QA validation of payment states, edge cases, and failure handling. Owned acceptance criteria for every payment touchpoint.
UX
Checkout experience design
Defined the UX for parent-facing checkout: payment breakdown clarity, instalment plan display, receipt generation, and error messaging designed for users with variable digital literacy on mobile.
Reporting
Transaction reporting workflows
Defined reporting requirements for finance teams across B2B and B2C streams, real-time collection dashboards, reconciliation exports, defaulter lists, and multi-school consolidation views.
Adoption
Rollout and training
Authored payment module documentation and training materials for finance staff. Monitored post-launch adoption and iterated on friction points identified through support tickets and usage data.
How I approached the integration
Design philosophy
Shared infrastructure. Separate experiences. No compromise on either.
payment gateway provided the payment rail. My job was ensuring the product layer on top of it was purpose-built for each persona, not a one-size-fits-all form that confused parents and frustrated accountants equally.
Started with finance team interviews, mapped every existing payment touchpoint, manual step, and reconciliation pain before touching specs
Separated B2C and B2B into distinct product tracks with independent specs, UX flows, and acceptance criteria, shared API layer, divergent experiences
Drove API sync validation with engineering, defined expected webhook states, failure recovery flows, and reconciliation logic for each payment type
Prioritised trust signals in B2C checkout, payment breakdown before confirmation, school name visible throughout, receipt auto-sent to parent on success
Built real-time reporting as a first-class feature, finance teams needed live collection data, not end-of-month exports. Defined the data model alongside the checkout flow.
The four payment flows delivered
B2C — Parent fee payment flow
B2C — Transport & activity booking flow
B2B — Staff salary disbursement
B2B — Vendor & partnership payments
What made it genuinely hard
Challenge 01
Multi-persona checkout on one platform
The same Payment gateway integration had to serve a parent paying a ₹5,000 term fee on a budget Android phone and a finance manager running a ₹2M payroll batch. The UX, error language, and trust signals needed to be completely different, without building two separate integrations.
Challenge 02
Reconciliation as a product feature, not an afterthought
Finance teams needed to close books daily, not at month end. This meant real-time transaction reporting had to be designed alongside the checkout flow, not bolted on afterward. Every payment type needed a defined data schema from day one.
Challenge 03
Trust and anxiety in parent checkout
Parent interviews revealed a consistent fear: 'Am I paying the right amount? Will the school receive it?' This anxiety drove specific design decisions, detailed breakdown before confirmation, school branding visible throughout, instant receipt, and a confirmation call-to-action for support. UX fixed the drop-off that API reliability alone couldn't.
Challenge 04
API failure states and edge case specs
Payment integrations fail. The product question was: what happens when they do? I worked with engineering to define every failure state, timeout, bank decline, partial capture, webhook delay, and wrote acceptance criteria for each. The goal was zero ambiguous states reaching the user.
What the payment platform delivered
4
Complete payment flows
B2C fees, bookings · B2B salary, vendor
50K+
Users on payment infrastructure
Parents, staff, finance teams, admins
Real-time
Financial reporting
Replaced end-of-month reconciliation
Collections
Digitised fee collection eliminated cash handling and manual ledger entries across 30–50 schools, reducing reconciliation errors and speeding up term-end close
Parent experience
Parents could pay fees, book transport, and register for activities from their phone, reducing school office footfall and payment delays significantly
B2B ops
Salary and vendor payment workflows moved inside Newton, finance teams gained audit trails, approval histories, and payroll registers in one place
Revenue impact
Payment module adoption contributed to subscription growth, schools with active payment workflows showed higher platform stickiness and lower churn
Visibility
Finance teams gained real-time collection dashboards across B2C and B2B streams, defaulter tracking automated, consolidated reports available on demand
Reliability
Defined failure-state handling and webhook validation reduced payment ambiguity, fewer support tickets, cleaner reconciliation, higher confidence in transaction data
Where I'd take it next
The payment infrastructure is proven. The next layer is intelligence, using the transaction data the platform generates to create predictive value for school finance teams.
Predictive fee collection & defaulter scoring
Use payment history to score collection risk by student, identify likely defaulters before the deadline, not after. Trigger proactive reminders with the right message and timing.
AI-driven revenue forecasting for school leadership
Surface expected term revenue, collection gap predictions, and cashflow projections for principals automatically, so they're making financial decisions on data, not guesswork.
Flexible instalment plans with automated follow-up
Enable schools to offer structured payment plans to parents who can't pay in full, with automated milestone reminders, partial receipt generation, and outstanding balance visibility.
Multi-school consolidated treasury view
For school groups managing 5–20 institutions, a single treasury dashboard showing collections, payables, and cashflow across every school, with drill-down per institution.
Want to talk product?
Open to Product Manager roles in SaaS, fintech, and edtech, Toronto, hybrid or remote.