feat: payment method blocking support from dashboard

[gitanjli525]

Type of Change

• Bugfix
• New feature
• Enhancement
• Refactoring
• Dependency updates
• Documentation
• CI/CD

Description

Adds a new Payment Method Blocking configuration section under Developer → Payment Settings → Payment Behaviour, allowing merchants to block specific card types on card and wallet payment methods from the dashboard.

Note: This feature is only applicable to Orchestration V1. The section is gated behind RenderIfVersion visibleForVersion=V1 and no changes are made to the V2 business profile types, mappers, or request payload.

UI changes (PaymentSettingsPaymentBehaviour.res)

• New PaymentMethodBlocking module rendered in the Payment Behaviour form, wrapped in RenderIfVersion visibleForVersion=V1
• Top-level "Payment Method Blocking" heading with a short description
• Two sub-sections — Card and Wallet — each with a multi-select dropdown (Credit / Debit) bound to payment_method_blocking.card.card_types and payment_method_blocking.wallet.card_types respectively
• Selections are persisted via the existing profile Update submit

Type & mapper changes (BusinessProfileInterface/…)

• New paymentMethodBlockingEntry and paymentMethodBlocking types in BusinessProfileInterfaceTypes.res
• Added payment_method_blocking field to commonProfileEntity, profileEntity_v1, and the V1 request type
• V1 JSON → typed parser (mapJsonToBusinessProfileV1) and typed → common mapper (mapV1toCommonType) wired to read/forward the new field
• V1 request mapper (commonTypeJsonToV1ForRequest) forwards payment_method_blocking on the update request
• V2 mapper (mapV2toCommonType) sets payment_method_blocking: None since the field is not supported on V2

The serialized shape sent on update / received on fetch (V1 only):

{
  "payment_method_blocking": {
    "card":   { "card_types": ["credit", "debit"] },
    "wallet": { "card_types": ["credit", "debit"] }
  }
}

Screen.Recording.2026-04-13.at.5.24.37.PM.mov

Motivation and Context

Merchants on Orchestration V1 need a self-serve way to block specific card types (credit / debit) for card and wallet payment methods on a business profile. Today this is only possible via the API. This PR surfaces the configuration in the dashboard alongside other payment behaviour settings.

Closes #4700

How did you test it?

Manual testing (V1):

• Ran npm run re:build — compiles cleanly
• Opened Developer → Payment Settings → Payment Behaviour on a V1 profile and verified the Payment Method Blocking section renders with Card and Wallet sub-sections
• Selected different combinations of credit / debit in both dropdowns and clicked Update — verified the payload contains the payment_method_blocking object with the expected shape
• Reloaded the page and verified the dropdowns hydrate from the saved payment_method_blocking response
• Verified that on a V2 profile, the Payment Method Blocking section is not rendered

Where to test it?

• INTEG
• SANDBOX
• PROD

Checklist

• I ran npm run re:build
• I reviewed submitted code
• I added unit tests for my changes where possible

[semanticdiff-com]

Review changes with  

[coderabbitai]

Walkthrough

New payment method blocking feature is introduced to business profile configuration. Type definitions are added to support blocking card and wallet payment methods by card type. Mapping utilities are updated across V1 and V2 interfaces to transform JSON configuration into domain types. A new React component enables UI-based configuration of these settings, and default values are initialized.

Changes

Cohort / File(s)	Summary
Type Definitions src/Interface/BusinessProfileInterface/BusinessProfileInterfaceTypes/BusinessProfileInterfaceTypes.res, BusinessProfileInterfaceTypesV1.res, BusinessProfileInterfaceTypesV2.res	Added new paymentMethodBlockingEntry and paymentMethodBlocking types with optional card and wallet fields. Extended commonProfileEntity and versioned profile entity types with optional payment_method_blocking field.
Mapping Utilities src/Interface/BusinessProfileInterface/BusinessProfileInterfaceUtils/BusinessProfileInterfaceUtils.res, BusinessProfileInterfaceUtilsV1.res, BusinessProfileInterfaceUtilsV2.res	Implemented JSON-to-domain mappers for payment_method_blocking field. Updated mapping functions across V1 and V2 utilities to parse nested card and wallet entries, handle empty dict checks, and propagate values through common type conversions.
UI & Configuration src/screens/Developer/PaymentSettingsRevamped/PaymentSettingsPaymentBehaviour.res, src/screens/Settings/MerchantAccountUtils.res	Added new PaymentMethodBlocking React component with multi-select inputs for card and wallet card types. Integrated component into Payment Behaviour settings form. Added payment_method_blocking: None default value to business profile defaults.

Estimated code review effort

🎯 3 (Moderate) | ⏱️ ~20 minutes

Poem

🐰 A new feature hops along so bright,
Payment methods now blocked just right,
Cards and wallets, types defined with care,
Mappers dance through versions fair,
Configuration UI blooms with delight! 🎯

🚥 Pre-merge checks | ✅ 3

✅ Passed checks (3 passed)

Check name	Status	Explanation
Title check	✅ Passed	The title clearly and specifically summarizes the main change: adding payment method blocking support to the dashboard UI and related type/mapping infrastructure.
Docstring Coverage	✅ Passed	No functions found in the changed files to evaluate docstring coverage. Skipping docstring coverage check.
Description Check	✅ Passed	Check skipped - CodeRabbit’s high-level summary is enabled.

_{✏️ Tip: You can configure your own custom pre-merge checks in the settings.}

✨ Finishing Touches

📝 Generate docstrings

• Create stacked PR
• Commit on current branch

🧪 Generate unit tests (beta)

• Create PR with unit tests
• Commit unit tests in branch feat/payment-method-blocking

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

❤️ Share

• X
• Mastodon
• Reddit
• LinkedIn

_{Comment @coderabbitai help to get the list of available commands and usage tips.}

[coderabbitai]

🧹 Nitpick comments (1)

src/Interface/BusinessProfileInterface/BusinessProfileInterfaceUtils/BusinessProfileInterfaceUtils.res (1)

167-171: Consider filtering out empty strings from card_types.

The mapper allows empty strings to be included in the card_types array when getStringFromJson("") falls back to its default. This could lead to unexpected behavior if the JSON contains null or invalid values in the array.

🔧 Proposed fix to filter empty values

 let paymentMethodBlockingEntryMapper: Dict.t<JSON.t> => paymentMethodBlockingEntry = entryDict => {
   card_types: entryDict
   ->Dict.get("card_types")
-  ->Option.map(json => json->getArrayFromJson([])->Array.map(item => item->getStringFromJson(""))),
+  ->Option.map(json => 
+    json
+    ->getArrayFromJson([])
+    ->Array.map(item => item->getStringFromJson(""))
+    ->Array.filter(s => s->LogicUtils.isNonEmptyString)
+  ),
 }

🤖 Prompt for AI Agents

Verify each finding against the current code and only fix it if needed.

In
`@src/Interface/BusinessProfileInterface/BusinessProfileInterfaceUtils/BusinessProfileInterfaceUtils.res`
around lines 167 - 171, The mapper paymentMethodBlockingEntryMapper currently
maps card_types using getArrayFromJson and getStringFromJson which can yield
empty strings; update the mapping so after converting each item to a string you
filter out empty strings (e.g., remove values equal to "" or only keep non-empty
strings) before returning card_types. Locate the card_types expression in
paymentMethodBlockingEntryMapper and add an Array filter step (after Array.map /
conversion) to exclude empty strings and ensure card_types is an array of only
non-empty string values.

🤖 Prompt for all review comments with AI agents

Verify each finding against the current code and only fix it if needed.

Nitpick comments:
In
`@src/Interface/BusinessProfileInterface/BusinessProfileInterfaceUtils/BusinessProfileInterfaceUtils.res`:
- Around line 167-171: The mapper paymentMethodBlockingEntryMapper currently
maps card_types using getArrayFromJson and getStringFromJson which can yield
empty strings; update the mapping so after converting each item to a string you
filter out empty strings (e.g., remove values equal to "" or only keep non-empty
strings) before returning card_types. Locate the card_types expression in
paymentMethodBlockingEntryMapper and add an Array filter step (after Array.map /
conversion) to exclude empty strings and ensure card_types is an array of only
non-empty string values.

---

ℹ️ Review info

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: d5a56e93-dba5-452e-a439-e4701a57a97e

📥 Commits

Reviewing files that changed from the base of the PR and between a1b7282 and 42047ba.

📒 Files selected for processing (8)

• src/Interface/BusinessProfileInterface/BusinessProfileInterfaceTypes/BusinessProfileInterfaceTypes.res
• src/Interface/BusinessProfileInterface/BusinessProfileInterfaceTypes/BusinessProfileInterfaceTypesV1.res
• src/Interface/BusinessProfileInterface/BusinessProfileInterfaceTypes/BusinessProfileInterfaceTypesV2.res
• src/Interface/BusinessProfileInterface/BusinessProfileInterfaceUtils/BusinessProfileInterfaceUtils.res
• src/Interface/BusinessProfileInterface/BusinessProfileInterfaceUtils/BusinessProfileInterfaceUtilsV1.res
• src/Interface/BusinessProfileInterface/BusinessProfileInterfaceUtils/BusinessProfileInterfaceUtilsV2.res
• src/screens/Developer/PaymentSettingsRevamped/PaymentSettingsPaymentBehaviour.res
• src/screens/Settings/MerchantAccountUtils.res

[muditbhutani]

@control_center_review_bot review this

[Riddhiagrawal001]

@control_center_review_bot can you review this

[muditbhutani]

Merge Confidence: 3.5/5 - Confident

"Looks good - minor concerns only"

Assessment

• ✓ Well-scoped, additive change — all new fields are option types, no breaking changes to existing records or APIs
• ✓ JSON mapper logic follows established codebase patterns (getDictfromDict + isEmptyDict guard), consistent with how external_vault_connector_details was added
• ✓ Type definitions properly shared across V1, V2, and common interfaces with correct cross-references
• ⚠ Wallet section label says "Card Types" and reuses credit/debit options — likely copy-paste error that will confuse users in production
• ⚠ getValueFromBusinessProfile in MerchantAccountUtils.res may not serialize payment_method_blocking to form initial values, meaning saved selections won't repopulate on page load
• ⚠ The card_types field name within the wallet entry type is semantically confusing — unclear if this is an API contract constraint or a modeling oversight

---

Review: Add payment method blocking to business profile settings

Adds a new "Payment Method Blocking" section to the payment settings UI, allowing merchants to block credit/debit card types for card and wallet payment methods. The data plumbing (types, JSON mappers, V1/V2 support) is solid and follows existing patterns. Two concerns: (1) the wallet section has copy-pasted labels/options from the card section that need wallet-specific text, and (2) form initial value serialization may be missing, causing saved values to not repopulate on load.

[hs-control-center-bot]

Verdict: 🔄 Request Changes

🚨 0 critical · ⚠️ 2 warning · 💡 0 suggestion · 🔍 1 nitpick

The incorrect label on the Wallet section impacts user clarity and should be fixed. The missing feature flag is a release management concern — confirm whether this feature should roll out unconditionally or be gated. The code is otherwise clean, follows existing patterns, and correctly wires the new field through all three API version mappers.

[hs-control-center-bot]

Verdict: 🔄 Request Changes

⚠️ 2 warnings · 🔍 1 nitpick

The PR introduces payment method blocking functionality with types, mappers, and a new UI component. Main concerns are the confusing duplicate "Card Types" label for wallets and the unconditional rendering of the feature. Consider whether this should be behind a feature flag for gradual rollout.