Feat/payment controller v2 support#1
Closed
foppe-nvv wants to merge 182 commits into
Closed
Conversation
0spinboson
force-pushed
the
feat/payment-controller-v2-support
branch
4 times, most recently
from
d56e025 to
89199ca
Compare
0spinboson
force-pushed
the
feat/payment-controller-v2-support
branch
5 times, most recently
from
54632e9 to
232a1b5
Compare
…s payable summary reports
fix: py error on sales forecase doctype
…ing in `get_outstanding_reference_documents` (frappe#54639)
…-fully-depreciated-asset-sale fix: skip depreciation rescheduling when asset is fully depreciated on sale
…frappe#54561) * fix(project): use user.email for invitations and skip disabled users. * Update erpnext/projects/doctype/project/project.py Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com> * fix(project): remove duplicate loop causing indentation error * fix(project): resolve pre-commit hook failure --------- Co-authored-by: coderabbitai[bot] <136622811+coderabbitai[bot]@users.noreply.github.com>
fix: show in and out qty in the stock ledger report for stock recos
* fix: mark item tax templates as not applicable For new German charts of accounts, mark accounts for different tax rates as *Not Applicable* in **Item Tax Templates**. * fix: wrong applicable rate 19 in template 7
fix: incorrect expense account book in purchase return
* fix: update frappe docker badge and link * remove pwd link
…appe#54699) * fix: set valid_from in created Item Price (frappe#54696) Co-authored-by: Kaajal-Chhattani <kaajal.chhattani@aurigait.com> (cherry picked from commit 6246a9a) # Conflicts: # erpnext/stock/get_item_details.py * chore: resolve conflicts --------- Co-authored-by: Kaajalchhattani <89331214+Kaajalchhattani@users.noreply.github.com> Co-authored-by: Mihir Kandoi <kandoimihir@gmail.com>
* ci: auto merge backports * ci: add github action to propogate auto-merge label
…pe#54711) (frappe#54712) Co-authored-by: Raffael Meyer <14891507+barredterra@users.noreply.github.com>
Add support for the new PaymentController interface from frappe/payments, enabling Payment Request to work with v2 gateways while maintaining backward compatibility with v1. Related: frappe/payments#192
…act/address handling
0spinboson
force-pushed
the
feat/payment-controller-v2-support
branch
from
13fdf35 to
b9e40a4
Compare
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
20 participants
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
Adds support for the new PaymentController interface from frappe/payments, enabling Payment Request to work with v2 payment gateways while maintaining backward compatibility with existing v1 gateways.
Related: frappe/payments#192
Documentation: frappe/frappe_io#332
Background
This PR is the ERPNext-side integration for the PaymentController architecture introduced in frappe/payments. It builds on the foundation laid by @blaggacao in:
frappe#40845 (original comprehensive refactor)
frappe#43085, frappe#43086 (attempted breakdowns)
Rather than refactoring existing Payment Request logic, this PR adds a branch that detects v2 gateways and routes them through PaymentController.initiate() while leaving v1 behavior untouched.
Changes
Gateway detection:
_is_v2_gateway() - Thin wrapper around payments.utils.is_v2_gateway() with import guard
New v2 flow methods:
_process_v2_gateway() - Calls PaymentController.initiate() and sets payment URL
get_tx_data() - Prepares transaction data matching the TxData interface
_get_party_contact_and_address() - Extracts payer contact/address info
Modified before_submit:
Routes to v2 or v1 flow based on gateway type
Email/communication handling unchanged
Design Decisions
Delegation to payments app: Gateway detection logic lives in payments.utils.is_v2_gateway() to avoid duplication and ensure consistency.
Request amount: Uses get_request_amount() (not grand_total) to support partial payment scenarios, consistent with existing phone payment flow.
Reference semantics: tx_data.reference_doctype/docname points to Payment Request (not the underlying invoice/order) because Payment Request handles callbacks and reconciliation.
Contact/address fields: Returns only payment-relevant fields rather than full document data.
Flow
Payment Request submitted
│
▼
Is v2 gateway?
/
Yes No
│ │
▼ ▼
process_v2 Legacy flow
gateway() (unchanged)
│
▼
PaymentController.initiate()
│
▼
Payment Session Log created
│
▼
/pay URL set
Dependencies
Requires frappe/payments with PaymentController support (frappe/payments#192).
Falls back gracefully when payments app lacks v2 support.
Test Plan
_is_v2_gateway() returns True for v2 gateways, False for v1
v2 gateway creates Payment Session Log via PaymentController.initiate()
v1 gateways continue working unchanged
Partial payment amounts handled correctly
Email sending respects mute_email flag for both flows