Practitionist / Practitionist/elluminar_web

EMI & education financing at checkout — WITH hardship/pause provisions

Open
#9 0 comments 0 reactions 0 assignees View on GitHub

Nobody has claimed this yet.

commerce payments post-mvp v1
Dominant language
TypeScript
Stars
1
Forks
0
Avg merge
17h 2m
Merged PRs (30d)
18

Description

Why / Context

PRD §8.6: EMI at checkout is "near-mandatory at the price points UpGrad, Edureka, and Crio.do operate at" — Capstone/Flagship and Career-tier annual prices sit exactly in that band. HARD REQUIREMENT from the teardown SKIP list: Crio's EMI partnerships produced consumer-complaint evidence of real harm (job loss with no payment pause); any partner we integrate must include explicit hardship/deferment provisions.

Schema already in place — NO migration required

  • Payment.method carries emi; provider EMI plans ride through Razorpay (Payment.raw holds tenure/issuer)
  • Subscription.pausedAt/resumesAt — hardship pause state for subscription-side relief
  • Order.metadata / OrderItem.metadata for financing-application refs (partner application id)
  • PlatformConfig for eligibility thresholds (min order value per method)

Implementation plan

  1. Phase 1 — Razorpay native EMI: enable card EMI / cardless EMI methods on Razorpay checkout for orders above threshold; display tenure/interest disclosure pre-payment; reconcile via existing webhook path (Payment.method='emi').
  2. Phase 2 — education-financing partner (Propelld/Financepeer-class): evaluation matrix MUST score hardship/deferment policy first (deal-breaker), then approval rates, payout timing, learner NPS.
  3. Partner flow: checkout "Pay with financing" → partner application handoff (redirect/embed) → application webhook → on disbursal, record Payment(provider: MANUAL, method: 'financing', raw: partnerPayload) and fulfill the order; store application ref in Order.metadata.
  4. Hardship UX: documented pause/deferment request path in learner billing settings that files a partner ticket AND pauses platform-side consequences (access retained per policy; Subscription.pausedAt where applicable).
  5. Refund interplay: financed orders refund to the financier — extend refund service routing by Payment.method; document learner-facing policy copy.
  6. Eligibility service: which items/totals surface financing (config-driven), soft credit-check disclosure copy.
  7. Legal/copy review of all disclosure screens (loops in issue #24 compliance pack).
  8. Rollout behind FeatureFlag('emi-financing'), Capstone+ price points first.

Acceptance criteria

  • Razorpay EMI tenure selection completes and fulfills like a normal capture
  • Partner-financed order fulfills on disbursal webhook; application state visible in admin order view
  • Hardship request path live and documented; pause honored platform-side
  • Refund of a financed order routes to the financier and is recorded correctly
  • No financing surfaces below the configured price threshold

Dependencies / sequencing

  • MVP M7 required. Partner contract is the long pole — start diligence immediately; teardown mandates hardship terms before launch, not after

Contributor guide

No contributing guide indexed for this repository

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

Research direction

Start by reviewing the existing Payment, Subscription, Order metadata, and PlatformConfig schema, then trace the Razorpay webhook and refund-service paths. Read the hardship requirements and issue #24 compliance dependency before assessing the checkout, financing webhook, learner settings, admin order view, and feature-flag entry points. Done requires all listed acceptance criteria, including threshold gating, hardship pauses, disbursal fulfillment, and financier refunds.

Written by the indexing model from the issue text.

Assessment

Tech stack
typescript
Domain
backend-api-design, payments
Issue type
Feature
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Mostly clear
Newbie friendliness
28/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.