feat: pluggable pay driver for "Pay and Submit"

[vorasmit]

What

Make the "Pay and Submit" action pluggable so a payment backend can change what it does without touching the button, label, checkbox toggle, or dialogs.

Today the flow is hard-wired: a checked make_bank_online_payment relabels the primary action to Pay and Submit → frm.savesubmit(), and the payout runs as the backend's on_submit side effect (submit-first). A backend that needs pay-first (e.g. an interactive bank OTP ceremony) had to fight this UX at runtime.

How

• New public/js/pay_drivers.js: a client registry keyed by integration_doctype — register_pay_driver(doctype, driver) / get_pay_driver(doctype). A driver is { form(frm), bulk(list_view, docs), add_fields }.
• Form: the primary action resolves the driver's form handler; default stays frm.savesubmit(). The action now also flips live when make_bank_online_payment is toggled, not only on reload.
• List: merges each registered driver's add_fields, and routes a selection per integration_doctype — driver-owned docs go to the driver's bulk, the rest run the existing OTP + bulk_pay_and_submit path. RazorpayX and another backend can coexist on one site.

Backward compatibility

No driver registered = exactly today's behaviour. RazorpayX is untouched. No server change.

Testing

Pure client JS. Bundle builds clean (bench build --app payment_integration_utils); all touched files pass node --check. Companion PR (bankbridge) registers the first real driver.

🤖 Generated with Claude Code

[coderabbitai]

Warning

Review limit reached

@vorasmit, you've reached your PR review limit, so we couldn't start this review.

Next review available in: 27 minutes

Enable usage-based reviews in Billing to review now. Otherwise, wait until the next included review is available.
You're only billed for reviews past your plan's rate limits ($0.25/file).

How can I continue?

After more reviews become available, a review can be triggered using the @coderabbitai review command as a PR comment. Alternatively, push new commits to this PR.

To avoid repeated limits, reduce automatic review volume by pausing incremental auto-reviews earlier, using label-based review opt-in, excluding WIP or generated PR titles, or requesting reviews manually when the PR is ready. If your team needs uninterrupted high-volume reviews, an organization admin can enable usage-based reviews.

How do review limits work?

CodeRabbit enforces per-developer PR review limits for each organization. Most developers receive the normal plan review availability.

For paid Pro and Pro+ PR reviews, CodeRabbit uses adaptive limits for sustained high-volume activity. When a developer's recent PR review activity reaches the 95th percentile or higher among CodeRabbit users, additional reviews become available more gradually as earlier reviews age out of the rolling window.

Please refer docs for additional details.

Review details

⚙️ Run configuration

Configuration used: Organization UI

Review profile: CHILL

Plan: Pro

Run ID: 63f0f0f7-de8e-45a7-9f04-099ae51ebc14

📥 Commits

Reviewing files that changed from the base of the PR and between 7103cff and 2cc562e.

📒 Files selected for processing (4)

• payment_integration_utils/payment_integration_utils/client_overrides/form/payment_entry.js
• payment_integration_utils/payment_integration_utils/client_overrides/list/payment_entry_list.js
• payment_integration_utils/public/js/pay_drivers.js
• payment_integration_utils/public/js/payment_integration_utils.bundle.js

---

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

[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: 5/5

Safe to merge — the change is purely additive client-side JS; existing RazorpayX behaviour is untouched when no driver is registered

The change is purely additive client-side JS with no server modifications. The two observations in payment_entry_list.js are non-breaking in the current codebase and can be addressed before or alongside the first real driver landing.

payment_entry_list.js — the driver routing and add_fields timing deserve a second look before the bankbridge companion PR merges

Important Files Changed

Filename	Overview
payment_integration_utils/public/js/pay_drivers.js	New driver registry — clean, minimal, idiomatic Frappe namespace extension with safe initialization and clear API surface
payment_integration_utils/public/js/payment_integration_utils.bundle.js	Adds pay_drivers import to the bundle — straightforward, no issues
payment_integration_utils/payment_integration_utils/client_overrides/form/payment_entry.js	Adds live checkbox toggle handler and driver-aware primary action lookup; guards are consistent with pre-existing conditions
payment_integration_utils/payment_integration_utils/client_overrides/list/payment_entry_list.js	Routing is well-structured; driver bulk receives unfiltered docs (eligibility not checked before dispatch), and add_fields is computed at definition time rather than lazily

_{Reviews (3): Last reviewed commit: "fix(payment-entry): alert on a mixed bul..." | Re-trigger Greptile}

[vorasmit]

Addressed the review in 2cc562e:

• Mixed selection now alerts and runs one payment flow instead of blocking the whole selection.
• The default path counts as a flow only when it has a payable doc, so a batch that just includes a few ineligible rows no longer trips the alert; those rows still show in the default confirm dialog's "to be skipped" section.
• Added a console.warn when a driver registers a form handler but no bulk handler (it would otherwise pay via the default RazorpayX path).

The empty-selection case needs nothing — Frappe keeps the bulk action disabled until a row is checked.