feat: let integrations narrow the PE transfer-method options (backport #51)

[mergify]

Add a payment_transfer_method_options hook: onload resolves the first registered resolver's non-empty list of allowed methods for the PE, and the PE client JS narrows the Select to it (resetting a now-invalid draft value to the first). No resolver / none installed -> the full default set, so razorpayx is unaffected; a resolver error degrades to the full set rather than breaking the form. Lets a bank integration hide UPI/Link its banks don't support without a global, install-order-dependent property setter.

---

This is an automatic backport of pull request #51 done by Mergify.

[mergify]

Tick the box to add this pull request to the merge queue (same as @mergifyio queue).

• Queue this pull request

[greptile-apps]

Confidence Score: 3/5

The UI narrowing works correctly but the allowed-methods constraint is not enforced during server-side validation, meaning the restriction can be bypassed through API calls or bulk submit.

validate() never calls _transfer_method_options to verify the submitted payment_transfer_method is in the hook-provided allowed list, so an API caller or bulk-submit flow can submit a PE with an excluded method and route a payment to a gateway that does not support it.

payment_entry.py — the validate/validate_transfer_methods path needs a check against the hook-resolved allowed set before the existing gateway-level validations run.

Important Files Changed

Filename	Overview
payment_integration_utils/payment_integration_utils/server_overrides/doctype/payment_entry.py	Adds _transfer_method_options hook resolver called at onload; validate() never checks the resolved allowed-methods list, leaving the restriction bypassable via API.
payment_integration_utils/payment_integration_utils/client_overrides/form/payment_entry.js	Adds apply_transfer_method_options which narrows the Select and resets an invalid draft value on refresh; the party_bank_account event can assign a method outside the narrowed set until the next refresh.

Comments Outside Diff (2)

1. payment_integration_utils/payment_integration_utils/server_overrides/doctype/payment_entry.py, line 52-76 (link)

   No server-side enforcement of hook-allowed methods

   validate() calls validate_transfer_methods which checks bank details, UPI ID, and contact info — but it never calls _transfer_method_options(doc) to verify that doc.payment_transfer_method is in the resolver's allowed set. The restriction is therefore client-side only: any API caller (e.g., bulk_pay_and_submit, a custom script, or a direct REST call) can submit a PE with a method the registered hook explicitly excluded, and the payment will proceed to the gateway with an unsupported method. Adding a guard inside validate_transfer_methods would close this gap.

2. payment_integration_utils/payment_integration_utils/client_overrides/form/payment_entry.js, line 116-122 (link)

   party_bank_account event ignores narrowed allowed methods

   When party_bank_account is cleared, the event unconditionally sets payment_transfer_method to LINK; when it is set, it resets to NEFT. If an integration's hook excludes LINK or NEFT from the allowed set, this creates a UI inconsistency: the narrowed Select no longer shows the just-assigned value, and the displayed value is invalid until the next form refresh triggers apply_transfer_method_options again.

_{Reviews (1): Last reviewed commit: "fix: keep transfer-method resolver conve..." | Re-trigger Greptile}

[resilient-tech-bot]

🎉 This PR is included in version 15.2.0 🎉

The release is available on GitHub release

Your semantic-release bot 📦🚀