Shalini Bansal

Shalini Bansal

Building products at global scale, with 12 years at PayPal. Deep expertise in payments, subscriptions, and fintech — solving complex customer and business problems.

Bengaluru, India
LinkedIn ↗ Download resume ↓ Explore independent work ↓

About me

I’ve spent my career at PayPal building payment products across Checkout, Subscriptions, and Billing Agreements — at the intersection of technology, customer behavior, and business. Building products from the ground up and rethinking others at scale taught me how customers behave, how to use data to make better decisions, and what it takes to build for millions of users.

What I’ve come to enjoy most is everything around the technology: understanding the problem, making sense of ambiguity, bringing perspectives together, and figuring out what is worth building. When we retired a subscriptions API, for example, the challenge wasn’t the replacement, but finding the right migration path for each merchant and moving about 200 of them without anyone losing a payment. The projects in this portfolio grew from similar problems I encountered at PayPal and reflect how I approach them: understanding the context, making trade-offs, shaping the solution, and defining success.

Payments is where I’ve built my depth, but not where my curiosity ends. I’m drawn to products where people make decisions, build trust, and change their behavior — and I’m excited to bring what I’ve learned in payments to those problems.

See full work experience →

Independent Product Work

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.

Design7recovery classes instead of one retry schedule
Modelled₹36–81Lmodeled annual recovery upside, one 50k-subscriber UPI AutoPay merchant
Target+5 ptstargeted recovery-rate lift vs. holdout (North Star metric)

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 spec ↗
Download (PDF)
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.

Measured100%root-cause accuracy on the holdout evaluation
Measured98%retry-decision accuracy in v2 evaluation
Design50eval-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 ↗
Download (PDF)
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.

Scenario800merchants in the worked example
Design6step path to migrate, from assess to sunset
Market3platforms 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 ↗
Download (PDF)
← All work
Read full spec ↗
Download (PDF)
Product Strategy · Payments, Subscriptions

Smart Retry and Recovery

Not every failed payment deserves another attempt.

UPI AutoPay allows four attempts per debit. Most platforms spend them on a fixed schedule, so a revoked mandate and a salary that lands two days late get the same treatment. Only one of them gets fixed by waiting.

So we treat attempts as a budget: spend one only when the failure’s cause says it can work, and re-decide after every response.

Diagnose first, then decide

Prevent what we can before the charge. If a payment still fails, classify it into one of seven types. Only three are fixable by retrying.

TODAY Any failed payment Same schedule, same message Only 3 of 7 causes are retry-fixable — the rest waste attempts SMART RETRY Prevent before the charge payday billing · expiry reminders · backup method if it still fails Classify into 7 failure types Retry at the right time 3 retry-fixable types Recover another way re-auth · new method Hold for review unknown or risk
Prevention comes first. If a payment still fails, it’s classified into seven types, then retried at the right time, recovered another way, or held for review.
3Fixable by retrying, at the right time
Insufficient fundsTemporary / operationalLimit or velocity
4Need another path: re-authorize, switch method, or review
Dead instrumentRevoked mandateCustomer action requiredUnknown / risk

Three calls that shape the product

Spend the retry only when it can work

Retries are a limited recovery budget, not calendar events. The failure class determines whether to retry, when to retry, or whether to stop.

Measure incremental recovery, not recovery

Some failed payments recover on their own. A holdout keeps the existing strategy, so we only credit the product for the difference.

Recover revenue without creating churn

Dunning can recover a payment and still lose the customer. Rollout pauses if dunning-attributed churn rises significantly versus holdout.

Here’s what that looks like for two customers who miss the same payment on the same day.

Same day, same ₹499, opposite answers

PPriya4 · Insufficient funds
RRahul1 · Dead instrument
PreventionBilled on the 1st by default — after two failures like this, she’s offered a move to the 3rdAn expiry reminder before the card lapsed would have let him update it before anything failed
What happenedHer ₹499 OTT payment fails on the 1st; her salary lands on the 3rdHis card expired, and the bank didn’t carry the mandate to the new one
Retry policyNext attempt held for the 3rd, not spent on the 1stNo retries — the card can’t be charged
What they hearNothing beyond her bank’s alert on the 1st; one nudge on the 2ndStraight away: “Your card has expired. Update it here.”
RecoveryNone needed — the retry on the 3rd succeeds that nightThree screens, one authentication, new mandate on UPI AutoPay
MeasureCounted in recovery rate, and in retry success for class 4Counted in recovery rate, and in re-authorization completion

The way it works todayBoth would get the same “payment failed, update your details” message. Priya’s retries would all land before payday, and Rahul’s would all hit a dead card.

The Full Product Spec

From decision logic to business case

The retry policy and messaging for all seven classes, recovery flows, metric design, and the experiment and rollout plan.

Read full spec ↗
Download spec (PDF)
Next case study Decline Decoder →
← All work
Read the write-up ↗
Download (PDF)
AI Product Live prototype — try it

Decline Decoder

A decline code like 05 – Do Not Honour can mean different things depending on the payment rail, the attempt number, and what happened last time. Read on its own, it tells you how to recover that one payment. Read alongside others, it reveals patterns no single decline can show.

The build story

The eval set

I wrote 50 decline scenarios by hand to build against, then held back 10 more that the product never saw during development — 98% retry-decision accuracy on the first set, 100% on the holdout, and 0 hallucinated causes on either, down from 4 of 5.

Open the eval set Open the eval-set results Open the lookup table
Decline code + context Lookup table Grounded, 88% accurate Can’t reason about context LLM alone Reasons about context Invented 4 of 5 unknowns Hybrid: LLM constrained to causes the table allows 98–100% 0 halluc.
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)

Neither method alone was reliable enough to ship — grounding the LLM in the lookup table is what took accuracy from 70–88% to 98–100% and hallucinations to zero.

Illustrative output, built from the product’s actual decision logic.

One decline, diagnosed

Pick a decline below to see what it decides.

declinediagnoser.app
Input
Decline code05 · Do Not Honour
RailUPI AutoPay
Context2nd attempt · plan price raised last week
Diagnosis
Re-authorize Retrying can’t succeed until the mandate is updated.
Root causeMandate cap is below the new plan price
Message to customer“Your plan price changed. Approve the new amount in one step to keep your subscription.”
Prevent next timeAsk for a fresh mandate before a price change goes live.
Input
Decline code51 · Insufficient funds
RailUPI AutoPay
Context1st attempt · billed on the 1st, salary usually on the 3rd
Diagnosis
Wait Hold the retry until after payday instead of spending it today.
Root causeBalance too low on the billing date
Message to customer“Your payment didn’t go through. We’ll try again on the 3rd — nothing to do.”
Prevent next timeLet the customer pick a billing date near payday.
Input
Decline code54 · Expired card
RailCard mandate
Context1st attempt · new card issued, mandate didn’t carry over
Diagnosis
Do not retry Every retry will fail — go straight to update.
Root causeCard expired and the mandate didn’t move to the new card
Message to customer“Your card has expired. Update it here to keep your plan running.”
Prevent next timeSend an expiry reminder a week ahead.
Diagnose a sample decline

Batch decline report, diagnosed

20 declines, read as one set — what’s worth retrying, what needs prevention, and what the money adds up to.

Batch view · 20 failed payments

Only ₹10,029 of ₹61,337 was worth retrying.

“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.

Run the sample batch →
Prevent before the charge₹39,443
Retry as-is₹10,029
Other₹11,865

Want the full story?

Why a lookup table alone wasn’t enough, how 60 hand-written test scenarios shaped the build, the guardrails that took retry accuracy from 70% to 98%, and when I’d kill the product. It’s all in the write-up.

Read the write-up ↗
Download (PDF)
Next case study Payments API Deprecation Playbook →
← All work
Read full playbook ↗
Download (PDF)
Platform Strategy · Merchant Migrations

Payments API Deprecation Playbook

How to retire a payment API without losing merchants or breaking payments.

Built from deprecations I led at PayPal: 40M+ daily API calls migrated with zero downtime, and ~200 merchants moved with zero escalations.

The Problem

Deprecating
an API is easy.Deprecating it safely
isn’t.

A payment API sits inside a merchant’s live payment flow. Retiring it safely means coordinating merchant effort, payment risk and engineering — not just picking a date.

  1. 01

    Money moves through it

    Lost transactions, revenue and customers — in real time.

  2. 02

    API success ≠ payment success

    Charges can migrate while refunds or webhooks still depend on the old path.

  3. 03

    The provider controls the date

    The merchant controls engineering, QA and release windows.

The Core Insight

Segment first.Then set the date.

Different merchants need different migration paths — segment first, then set the sunset date around what each group can safely support.

The Worked Example

18 merchants carry 78% of the payment volume.

Give all 800 the same deadline, and you over-serve the long tail while under-serving the accounts that can break the migration. So the playbook segments first, and sets a sunset date per segment only after that.

18 · 78%
782 · 22%

One migration path per segment

TierMerchantsShare of TPVMigration path
High-volume1878%Code change, white-glove support
Plugin-based4006%One-line upgrade
Long tail1322%Compatibility layer, no merchant effort

And “migrated” doesn’t always mean migrated.

88% of merchants had moved, but only 62% of volume — two accounts held almost the entire gap. A brownout surfaced the real risk: charges had moved to the new API, but refunds for those same merchants hadn’t.

What the dashboard said
Merchants migrated
88%
Volume migrated
62%

Same migration, two different stories. Both get their own dashboard.

What the brownout found
ChargesNew API
RefundsOld API, still

A merchant marked “done” would have lost refunds at cutoff.

The Operating Model

Six steps, in this order

Merchants are segmented and a path chosen for each before any deadline is picked.

  1. 01AssessIs migration even the right call?
  2. 02SegmentBy five factors, not size or tenure alone.
  3. 03Choose pathA different path for each segment.
  4. 04MigrateSegment by segment, with support where the volume is.
  5. 05MeasureMerchants and volume on separate dashboards.
  6. 06SunsetFive enforcement stages, not one cutoff date.
The Full Playbook

How do you actually run this?

The full spec: merchant segmentation, communication cadence, dashboards, enforcement stages, rollback triggers, and a Stripe / Razorpay / Cashfree teardown.

Read full playbook ↗
Download playbook (PDF)
Next case study Smart Retry and Recovery →
← All work
Professional Experience

At PayPal, I’ve built products where a great experience isn’t enough; payments also have to be reliable and work at scale. The work below highlights three outcomes I’m particularly proud of: improving checkout conversion, making payments more reliable, and leading large-scale change without disrupting customers.

10%mobile checkout conversion lift
10xfewer failed-payment incidents
40M+daily API calls migrated, zero downtime
Checkout · Billing Agreements & SubscriptionsPayPal — Product & Tech Lead
Sep 2021 – Nov 2025

Bengaluru, India

  • 10% lift in mobile checkout conversion — shaped the strategy and owned the PRD and roadmap for native checkout screens, with experiments designed to measure their impact on mobile flows.
  • Spotted a recurring reliability gap during planned database maintenance that was silently failing customer payments, and drove the fix 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 the cutover by merchant risk — migrating 40M+ daily API calls with zero downtime.
  • Drove the deprecation of a subscriptions API used by ~200 merchants, weighing replacement paths against merchant effort and long-term value, then led the migration with zero reported complaints or escalations.
QR PaymentsPayPal — Software Engineer 3
Jan 2020 – Sep 2021

San Jose, USA

  • Shaped the product scope and sequencing for PayPal QR payments, assessing technical feasibility and translating product objectives into a roadmap engineering could commit to.
  • Defined seller-side risk policy for QR payment acceptance, balancing fraud controls against checkout friction for legitimate sellers.
  • Enabled Venmo-to-PayPal QR payments, expanding the payer network available to PayPal merchant acceptance.
IncentivesPayPal — Software Engineer 1–2
Jul 2014 – Jan 2020

Bengaluru / San Jose

  • Built and shipped a batch-processing system that issued targeted offers via high-volume file uploads, reaching millions of users.
  • 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

What I bring to a product team

Domain

Payments Recurring billing & subscriptions Checkout QR payments Fraud & risk Merchant platforms

Product

PRD authorship Roadmap ownership A/B testing Funnel analysis Cross-functional negotiation Merchant comms Trade-off framing

AI

LLM application design Evaluation design Guardrails and grounding Prompt engineering Rapid prototyping

Technical

Distributed systems Microservices API design & deprecation System reliability SQL Java
Back to All work ↑