AVAILABLE FOR NEW OPPORTUNITIES

Shalini Bansal

I spent 12 years at PayPal building systems that power millions of payments. Now I’m focused on solving complex problems at the intersection of payments, product, and customer experience.

Bengaluru, India

LinkedIn ↗ Download resume ↓ See the work ↓

About me

At PayPal, I worked across Billing Agreements, Subscriptions, and Checkout — where decisions directly shaped conversion, revenue, and customer experience. That work translated into measurable outcomes:

10%checkout conversion lift

10xfewer failed-payment incidents

40M+daily API calls migrated, zero downtime

The projects in this portfolio grew out of problems I experienced firsthand while working on PayPal’s Checkout team: recovering failed payments, decoding payment declines, and safely sunsetting APIs that merchants still depend on. I approached each as a product problem—from defining the problem and understanding users to shaping the strategy, evaluating trade-offs, designing the solution, and defining how success would be measured.

My portfolio today is more payments-focused — that’s where I’ve built depth, but not where I intend to stop. I’m just as interested in consumer behavior, trust, and decision-making, wherever they show up.

See full work experience →

Independent Product Work

Problems, worked end to end

Product Spec · Subscriptions

Smart Retry and Recovery

A failed recurring payment shouldn’t automatically trigger another retry. The right recovery depends on why it failed, what can change, and what the customer should do next.

74%of UPI AutoPay declines are business, not technical.

7recovery classes instead of one retry schedule

₹36–81Lmodeled annual recovery upside, one 50k-subscriber merchant

Prevent, classify, retry or recover — in that order. Prevention comes first because it’s the best recovery there is — keeping a backup instrument on file, sending expiry-card reminders, and catching failures before the charge ever happens. Failures are classified into seven recovery classes, then retried only when mandate state and retry attempt budget allow it — or recovered through re-authorization, a payment-method switch, or a guiding message.

The core product question

Given what we know about this failure, what is the highest-probability path to recovery?

See the highlights → Read full specs ↗

AI Product · Working Prototype

Decline Decoder

Turning cryptic payment decline codes into a recovery decision — grounded in payment rules, but able to reason about the transaction context.

100%root-cause accuracy on the holdout evaluation

98%retry-decision accuracy in v2 evaluation

50eval-set scenarios, written before the product was built

A hybrid model pairs a lookup table for facts with an LLM for reasoning — grounded, not guessing. For every decline it returns a root cause grounded to the lookup table, retry guidance on whether to wait, retry, or escalate, a customer-facing recovery message ready to send, and a prevention step for next time.

The product lesson

Don’t ask the LLM to be the source of truth. Give it reliable facts, then let it reason over context.

See the highlights → Open the live tool ↗ Read the write up ↗

Platform Strategy · Merchant Migrations

Payments API Deprecation Playbook

A practical operating model for retiring a payment API without treating merchant migration as a simple engineering upgrade.

800merchants in the worked example

6step path to migrate, from assess to sunset

3platforms benchmarked · Stripe, Razorpay, Cashfree

Deprecating a payment API risks merchant churn and payment failures if it’s rushed — this playbook turns it into a six-step model that reduces that risk. It starts by assessing whether migration is even the right call, then segments merchants, assigns a path per segment, and enforces the cutover in five stages — tracking merchant count and TPV on separate dashboards.

The core operating principle

Segment before the sunset date, not after. The goal isn’t the cleanest architecture — it’s the safest path with the least disruption to merchants.

See the highlights → Read full playbook ↗

← All work

Product Strategy · Payments, Subscriptions

Smart Retry and Recovery

Most subscription platforms retry every failed payment on the same fixed schedule, with the same message — spending attempts that UPI AutoPay strictly caps. A card that’s genuinely dead gets treated exactly like a payment that would’ve gone through days later, once the salary lands.

This page covers the highlights — for the full detail, open the spec below.

Read full specs ↗

One fixed retry schedule vs. classifying the failure first, then choosing prevention, retry, or re-authorization.

Dead instrument Revoked mandate Customer action required Insufficient funds Temporary / operational Limit or velocity Unknown / risk

Blue dot = genuinely retry-viable. The other three classes need prevention or re-authorization instead.

Two customers, same day · different recovery
	Priya · short of funds	Rahul · card expired
What happened	Her ₹499 OTT payment fails on the 1st; her salary lands on the 3rd	His ₹499 payment fails because his card expired, and the bank didn’t carry the mandate to the new one
Class	4 · Insufficient funds	1 · Dead instrument
Retry policy	Next attempt held for the 3rd, not spent on the 1st	No retries — the card can’t be charged
What she/he hears	Nothing on the 1st beyond her bank’s alert; one nudge on the 2nd	Straight away: “Your card has expired. Update it here.”
Recovery	None needed — the retry on the 3rd succeeds that night	Three screens, one authentication, new mandate on UPI AutoPay

Under today’s fixed schedule, both would get the same “payment failed, update your details” message. Priya’s retries would all land before her salary; Rahul’s would all hit a dead card.

Prevention

Customers pick their own billing date, close to payday
Backup instrument or mandate kept on file before a failure happens
Expiry reminders sent a week ahead, not after the decline

Intelligent retries

Insufficient-funds failures retried near salary day, not on a fixed date
Temporary failures retried as soon as bank health recovers
No retry at all when another attempt can’t fix it

Dunning & messaging

Content, frequency, and channel all follow the recovery class
No one-size-fits-all reminder on a fixed schedule

Recovery flows

Multiple recovery flows, chosen by the customer action actually needed
Most important: re-authorizing a mandate
Simple, fast, low-friction — shouldn’t feel like signing up again

Metrics

Headline metric: recovery rate, supported by 6 supporting metrics
One counter-metric catches customer harm from dunning
Every metric compared against a holdout, since some failures recover without help

Rollout is tied to two metrics that pull against each other — recovery rate, and a counter-metric for dunning-attributed churn — plus one fully specified A/B test, phased starting with low-ticket UPI AutoPay merchants.

Read full specs ↗

Next case study Decline Decoder →

← All work

AI Product · Working Prototype

Decline Decoder

A decline code like 05 – Do Not Honour means something different depending on the rail, the attempt number, and what happened last time. Read one at a time it’s a recovery decision; read as a set, it surfaces insights no single decline can show. I built the eval set before I built the product.

This page covers the highlights — for the full detail, open the live tool or the write-up below.

Open the live tool ↗ Read the write up ↗

The eval set

50 hand-written scenarios in the dev set, plus a 10-scenario frozen holdout — written before the product was built.

Open the eval set ↗

Neither the lookup table nor the LLM alone is enough — the hybrid keeps the LLM's reasoning inside what the table can ground.

Retry-decision accuracy by approach

Lookup only

88% · 0/5 halluc.

v1 — AI only

70–74% · 4/5 halluc.

v2 hybrid (dev, n=50)

98% · 0/5 halluc.

v2 hybrid (holdout, n=10)

100% · 0/2 halluc.

Single method Hybrid (shipped)

Grounded, not guessing

The model only reasons inside what the lookup table can verify — zero hallucinations on unknown codes.

Speed has a price

Grounding costs ~7.2s/₹0.8 a check vs. ~3.3s/₹0.3 ungrounded — worth it off the live payment path.

Advises, doesn’t decide

Fraud and lost-card messages route to pre-approved templates, not free-text generation — and agents can override every call.

Open the eval-set results ↗

From one decline to a portfolio

The live tool doesn’t stop at one decline — a batch view rolls a full set of declines into one read. In an example run of 20 failed transactions, here’s what the tool surfaced: what’s worth retrying, what needs prevention instead, and what the money adds up to.

Few insights it surfaced with possible fixes

“Price changes are breaking mandates,” “customers cancelling mandates outside the product,” and “debits landing before customers are paid” — each invisible one decline at a time, obvious once read as a set.

Retry

₹10,029 of the batch’s ₹61,337 is worth another attempt as-is — the rest just spends attempts.

Prevent

₹39,443 needs a fix before the charge, not after it — the larger share of the value at stake.

Message

Every decline gets a customer-facing message matched to why it actually failed, not a generic “please retry” prompt.

Next case study Payments API Deprecation Playbook →

← All work

Platform Strategy · Merchant Migrations

Payments API Deprecation Playbook

Money moves through the API you’re retiring. A merchant can’t just upgrade when convenient — and the provider controls the deadline while the merchant controls the release.

This page covers the highlights — for the full detail, open the playbook below.

Read full playbook ↗

The six-step framework — merchants are segmented and a replacement path chosen before a deadline is picked.

01 · Assess

What the legacy system costs to keep running today, what migration will actually cost, and whether merchants have a real reason to move — before assuming migration is the right call at all.

02 · Segment

Merchants split by five factors — impact, technical complexity, ability to migrate, contract terms, and how much control they have over their own release — not by tenure or size alone.

03 · Choose path

A migration path assigned per segment: a code change with white-glove support for high-volume merchants, a one-line upgrade for the plugin-based bulk, a compatibility layer for the long tail.

04 · Migrate

Execution runs segment by segment, not all at once — so the highest-impact accounts get the most support and the long tail isn’t blocked on custom work it doesn’t need.

05 · Measure

Merchant count and TPV migrated tracked on separate dashboards — the two tell different stories, and a handful of accounts can hold almost all of the remaining gap.

06 · Sunset

Enforcement escalates in five stages — warning, friction, brownouts, controlled cutoff, retirement — not one cutover date that catches merchants who still aren’t ready.

Worked example (800 merchants) · Segmentation
Tier	Share of merchants	Migration path
High-volume	18 merchants · 78% of TPV	Code change, white-glove support
Plugin-based	Bulk of the base	One-line upgrade
Long tail	Remainder	Compatibility layer, no effort required

18 merchants · 78% of TPV

782 merchants · 22%

Merchant count vs. transaction volume migrated

Merchants migrated

88%

TPV migrated

62%

Merchants TPV

Two accounts held almost the entire remaining gap — merchant count and TPV migrated tell different stories, so both get their own dashboard.

One brownout revealed something the migration hadn’t caught: merchants whose charge flow had moved to the new API, but whose refund endpoints hadn’t — still pointed at the old one. Enforce the cutover too fast, and a customer’s refund gets stuck mid-flight.

Read full playbook ↗

Back to the start Smart Retry and Recovery →

← All work

Professional Experience

Work Experience

Product-oriented technology leader with 12 years of experience building and scaling customer-facing products, with deep expertise in payments and checkout.

Skilled at translating ambiguous business and technical problems into concrete PRDs, roadmaps, and experiments. At PayPal, drove product ownership across key Billing Agreements, Subscriptions, and Checkout initiatives — delivering a 10% lift in checkout conversion through native checkout screens, improving payment reliability 10x, and independently initiating a zero-downtime migration of 40M+ daily API calls.

Professional Experience

PayPal — Staff Software Engineer (De Facto Product Manager) Sep 2021 – Nov 2025

Checkout — Billing Agreements & Subscriptions · Bengaluru, India

Authored PRD and roadmap for native Checkout screens, designing the experimentation framework that isolated conversion impact and delivered a 10% lift in checkout conversion.
Diagnosed recurring payment reliability gaps during database maintenance and led a cache-bridge solution that lifted Billing Agreement reliability from 99.99% to 99.999%, cutting failed-payment incidents 10x.
Self-initiated the deprecation of a legacy monolith, negotiating migration timelines with 10+ upstream teams and sequencing cutover by merchant risk; migrated 40M+ daily API calls with zero downtime.
Drove the deprecation of a subscriptions API used by ~200 merchants, evaluating replacement paths across merchant effort and long-term value, and leading merchant segmentation and migration communications with no reported complaints or escalations.
Owned experimentation and ramp strategy for native-app checkout authentication, contributing to a 40% reduction in checkout drop-off; led funnel analysis and cross-team instrumentation across five organizations to identify and resolve re-authentication friction.

PayPal — Software Engineer 3 Jan 2020 – Sep 2021

QR Payments · San Jose, USA

Shaped product scope and sequencing for PayPal QR payments, assessing technical feasibility and effort to translate product objectives into executable roadmap commitments.
Built seller-side risk policy checks into QR payment acceptance against Risk-team-defined policy, balancing fraud controls with checkout friction for legitimate sellers.
Enabled Venmo-to-PayPal QR payments, expanding the payer network available to PayPal merchant acceptance.

PayPal — Software Engineer 1–2 Jul 2014 – Jan 2020

Bengaluru / San Jose

Built a batch processing system issuing targeted offers to millions of users via high-volume file uploads.
Owned the migration of eBay Gift Cards from PayPal to eBay systems during the post-split separation, coordinating across teams to avoid customer-facing disruption.

Skills

Product

PRD authorship, roadmap ownership, experimentation & A/B testing, funnel analysis, cross-functional negotiation, merchant migration & communications, trade-off framing.

Domain

Payments, recurring billing & subscriptions, checkout, QR payments, fraud & risk, merchant platforms.

Technical

Distributed systems, microservices architecture, API design & deprecation, system reliability, SQL, Java.

Education

B.Tech, Information Technology — Vellore Institute of Technology 2010 – 2014

GPA: 9.10 / 10 · Vellore, India

Back to All work ↑