The Razorpay row on the payment step

This is the one screen where an Indian donor hands over money. Today the row that takes that money is drawn as a bank.

Today

Rendered at the two widths that matter: a phone column and the desktop card. The worst case is a host that has Stripe, PayPal, Razorpay and bank transfer all switched on.

Recommended

Why the label reads this way

• UPI first. This is already the settled direction for this fork — see Contribute in rupees: “upstream leads with card because its rails are American; for an Indian contributor that ordering is backwards.” The current string has it the other way round.
• “& more” is where netbanking went. A donor who banks with SBI and wants netbanking is looking for that word. Spelling it out costs three syllables.
• Razorpay moves to the subtitle because that is where it earns its keep. Nobody picks a payment method by its processor. What the processor's name genuinely buys is the answer to “who is getting my card number” — which is a trust sentence, not a title.
• It becomes translatable. The current title is a bare JavaScript string; every neighbour is a FormattedMessage. As written it can never be shown in Hindi or Malayalam.

Why not the Razorpay logo

• This list de-brands on purpose. PayPal's mark is in the repo already — and it is drawn in three greys (#E0E4EB, #C4C9D1, #CFD2D7), not PayPal blue. The house grammar is shape without brand colour. A brand-blue Razorpay mark would be the only advertisement in the column.
• Recolouring somebody's trademark is worse than not using it. Following the PayPal precedent means shipping a modified Razorpay mark. Razorpay's brand page (razorpay.com/brand/) returns 404 and the newsroom page states only that marks are “subject to Razorpay's Usage Agreement”, which I could not read. I will not hand over a trademark I could not verify the terms for.
• It is off-direction. The established mock for this flow uses words and no logos at all.
• If someone later obtains the official asset and the usage terms, the unmodified mark in the subtitle position is the version to argue for — not a grey redraw in the icon slot.

Icons I tried and rejected

• A credit card outline. Clean, but it duplicates the “New credit/debit card” row above whenever a host runs Stripe as well, and it under-sells UPI.
• A QR code. Reads instantly as UPI in India — but a donor on a phone never scans anything; Razorpay hands off to their UPI app. An icon that promises a mechanism the donor will not get is the same class of error we are fixing.
• A wallet. Ambiguous at 20px; reads as an envelope.
• A house-drawn card or phone with ₹ on it. Rendered and looked at: at 26 × 18 the rupee sign is a grey smudge. Legible in the source, invisible on the screen.
• The rupee sign alone (chosen). It is the one claim on this row that can never be found false, it is the most legible of the set at 20px, and it collides with neither neighbour. The words carry the information; the icon just has to be quiet and true.

The change

Two files. Everything is additive or in-place; no component is restructured.

1. lib/payment-method-utils.js — stop drawing a bank

import React from 'react';
import { Bank } from '@styled-icons/boxicons-solid/Bank';
+import { IndianRupee } from 'lucide-react';
…
  } else if (service === PAYMENT_METHOD_SERVICE.RAZORPAY) {
-    // No dedicated icon yet — Razorpay is a card/UPI aggregator, a bank icon reads closer
-    // than a generic credit card would.
-    return <Bank size={size} />;
+    // Deliberately not a bank: the manual bank-transfer row already uses a Landmark icon,
+    // and Razorpay is UPI-first. Deliberately not the Razorpay mark either — this list
+    // de-brands (see the grey PayPal icon). ₹ is the one claim that is always true here.
+    return <IndianRupee size={size || 20} className="h-5 w-5" />;
  } else if (type === PAYMENT_METHOD_TYPE.PREPAID) {

lucide-react is already a dependency and is what the manual payment providers in this same list use (Landmark, HandCoins). No new package.

2. components/contribution-flow/utils.js — the words

    // Razorpay
    if (hostHasRazorpay && !disabledPaymentMethodTypes?.includes(PAYMENT_METHOD_TYPE.PAYMENT)) {
      uniquePMs.push({
        key: 'razorpay',
-        title: 'Razorpay (Cards, UPI & more)',
+        title: (
+          <FormattedMessage
+            id="ContributePayment.razorpay"
+            defaultMessage="UPI, cards & netbanking"
+          />
+        ),
+        subtitle: (
+          <FormattedMessage
+            id="ContributePayment.razorpaySubtitle"
+            defaultMessage="Handled by Razorpay — {collective} never sees your card details."
+            values={{ collective: collective.name }}
+          />
+        ),
        paymentMethod: {
          service: PAYMENT_METHOD_SERVICE.RAZORPAY,

FormattedMessage is already imported in this file, and subtitle is already rendered by PaymentMethodList.tsx (the manual providers use it). Confirm the in-scope variable holding the collective before wiring {collective} — if it is awkward, drop the variable and use “Handled by Razorpay. Your card details are never shared with us.”

Also wrong on this step, for an Indian donor

• Razorpay is last, and the default selection is wrong because of it. The options are built in order: Stripe element, saved cards, new card, PayPal, then Razorpay, then Alipay, then bank transfer. PaymentMethodList auto-selects the first enabled option — so on a host with both, an Indian donor lands with a card or PayPal pre-selected and has to notice and change it. Moving the Razorpay block above the “New credit card” block is a cut-and-paste of one block and fixes both the order and the default. I would do it as a separate commit from the icon.
• “Payment info” is the step's name, but you enter no payment info here. Minor, upstream, not worth a patch on its own.
• Currency is right, grouping is the browser's. formatCurrency passes no locale, so toLocaleString uses the visitor's. An Indian browser gets ₹1,00,000; an American one gets ₹100,000. Below ₹1 lakh the two agree, so this only bites on large gifts. Worth pinning to en-IN for INR eventually; not part of this patch.
• “₹1,400.00 INR” in the summary rail says rupees three times. Harmless, and out of scope for this step.

Two things I saw that are somebody else's call

• The Razorpay sheet says the Collective is the merchant. PayWithRazorpayButton passes name: collective.name, so the donor's payment sheet — and likely their bank SMS — names the Collective, while the money settles into the fiscal host's Razorpay account. If those are different legal entities, that is a mismatch on the most scrutinised screen in the flow. I could not check whose account the key belongs to.
• Nothing is prefilled. Razorpay Checkout accepts prefill: { name, email, contact }. The flow already collected name and email one step earlier, so the donor is retyping them into the sheet on a phone. Three lines of config, not a feature — but it is a change to the payment call, so it belongs to whoever owns that file.

What I could not check

• I never saw the live payment step. The running fork's frontend stopped hydrating partway through this session — the details and profile steps rendered, then the dev bundle stalled at seven JS chunks and the page went blank while a builder was editing the repo. Every specimen above is built from the shipping component's own values (PaymentMethodList.tsx, payment-method-utils.js, lucide-react, the repo's own icon SVGs) and rendered and measured in Chrome — but in a harness, not on the real page. Somebody should look at the real step once the app is back up. The prediction to check: the Razorpay icon measures 26 × 26 and the bank-transfer icon 20 × 20; after the patch both are 20 × 20.
• Razorpay's trademark terms. razorpay.com/brand/ is a 404; the newsroom page names a Usage Agreement it does not show.
• Whether any real Indian host runs Stripe alongside Razorpay. That decides whether a card icon would have collided; it does not change the recommendation.