Business Manager Orders: PSP reference linking for partial payment orders

[milica-popovic-yemora]

Show both PSP reference links for partial payment orders

Summary

For partial payment orders, the PSP reference used for links in Business Manager was resolved from the order level, resulting in only the last transaction’s PSP reference being displayed and linked.

This change updates the PSP reference resolution to be transaction-based, so each payment transaction exposes its own PSP reference. This ensures correct linking for all payment instruments involved in a partial payment order.

Tested scenarios

• Credit Card + SVS partial payment order
• Verified that each transaction displays and links to its own PSP reference in Business Manager
• Verified no behavior change for single-payment orders

Fixed issue:

[gemini-code-assist]

Summary of Changes

Hello @milica-popovic-yemora, I'm Gemini Code Assist¹! I'm currently reviewing this pull request and will post my feedback shortly. In the meantime, here's a summary to help you and other reviewers quickly get up to speed!

This pull request addresses an issue where Business Manager was incorrectly displaying only the last PSP reference for partial payment orders. By shifting to a transaction-based PSP reference resolution, the system now accurately links each payment instrument to its specific PSP reference, significantly improving the clarity and usability of order details for multi-payment scenarios.

Highlights

• Improved PSP Reference Linking for Partial Payments: Previously, for partial payment orders, only the PSP reference of the last transaction was displayed and linked in Business Manager. This change updates the system to resolve PSP references on a per-transaction basis.
• Transaction-Based PSP Reference Resolution: The resolution of PSP references is now transaction-based, ensuring that each individual payment transaction within a partial payment order exposes and links to its own correct PSP reference.
• Accurate Linking for All Payment Instruments: This enhancement guarantees correct linking for all payment instruments involved in a partial payment order, providing a more comprehensive and accurate view in Business Manager.
• No Impact on Single-Payment Orders: The changes have been verified to have no behavioral impact on single-payment orders, maintaining existing functionality where it is not applicable.

🧠 New Feature in Public Preview: You can now enable Memory to help Gemini Code Assist learn from your team's feedback. This makes future code reviews more consistent and personalized to your project's style. Click here to enable Memory in your admin console.

Using Gemini Code Assist

The full guide for Gemini Code Assist can be found on our documentation page, here are some quick tips.

Invoking Gemini

You can request assistance from Gemini at any point by creating a comment using either /gemini <command> or @gemini-code-assist <command>. Below is a summary of the supported commands on the current page.

Feature	Command	Description
Code Review	/gemini review	Performs a code review for the current pull request in its current state.
Pull Request Summary	/gemini summary	Provides a summary of the current pull request in its current state.
Comment	@gemini-code-assist	Responds in comments when explicitly tagged, both in pull request comments and review comments.
Help	/gemini help	Displays a list of available commands.

Customization

To customize Gemini Code Assist for GitHub experience, repository maintainers can create a configuration file and/or provide a custom code review style guide (such as PEP-8 for Python) by creating and adding files to a .gemini/ folder in the base of the repository. Detailed instructions can be found here.

Limitations & Feedback

Gemini Code Assist may make mistakes. Please leave feedback on any instances where its feedback is incorrect or counter productive. You can react with 👍 and 👎 on @gemini-code-assist comments. If you're interested in giving your feedback about your experience with Gemini Code Assist for Github and other Google products, sign up here.

You can also get AI-powered code generation, chat, as well as code reviews directly in the IDE at no cost with the Gemini Code Assist IDE Extension.

Footnotes

1. Review the Privacy Notices, Generative AI Prohibited Use Policy, Terms of Service, and learn how to configure Gemini Code Assist in GitHub here. Gemini can make mistakes, so double check it and use code with caution. ↩

[sonarqubecloud]

Quality Gate passed

Issues
0 New issues
0 Accepted issues

Measures
0 Security Hotspots
0.0% Coverage on New Code
0.0% Duplication on New Code

See analysis details on SonarQube Cloud

[gemini-code-assist]

Code Review

This pull request correctly addresses the issue of displaying PSP references for partial payments by iterating through payment instruments. The core logic change is sound. However, I've identified a couple of areas for improvement in the implementation. The new logic for multiple payments introduces invalid HTML and UI inconsistencies compared to the single payment view. I've provided a suggestion to refactor this into a single, simplified loop that handles all cases correctly and consistently. I've also included a minor suggestion to improve code conciseness.

[gemini-code-assist]

The logic to handle single and multiple payment instruments can be greatly simplified. The current implementation has a few issues:

1. Code Duplication: The <isif> and <iselse> blocks contain very similar logic for displaying payment information.
2. Inconsistent UI: The layout for multiple payments (three columns in one row) is different from the single payment layout (two columns over two rows).
3. Invalid HTML: The multi-payment case renders three <td> elements in a <tr>, but the table's <thead> only defines two columns, which is invalid HTML and can cause rendering issues.
4. Empty Rows: The loop for multiple payments can render empty <tr> elements if a payment instrument has no PSP reference.

A single loop over all payment instruments can handle all cases (0, 1, or many) correctly and consistently. This removes the need for the isif/iselse check on the number of instruments and resolves all the issues mentioned above.

		<isloop items="${order.getPaymentInstruments()}" var="paymentInstrument" status="piStatus">
			<isif condition="${paymentInstrument.paymentTransaction.custom.Adyen_pspReference != null}">
				<tr>
					<td class='infobox_title'>PSP reference</td>
					<td class='infobox_item'>
						<A target='new' HREF='https://ca-${urlPrefixType}.adyen.com/ca/ca/accounts/showTx.shtml?pspReference=${paymentInstrument.paymentTransaction.custom.Adyen_pspReference}&txType=Payment'>
							<isprint value="${paymentInstrument.paymentTransaction.custom.Adyen_pspReference}">
						</A>
					</td>
				</tr>
				<tr>
					<td class='infobox_title'>Payment Method</td>
					<td class='infobox_item'><isprint value="${paymentInstrument.custom.adyenPaymentMethod}"></td>
				</tr>
			</isif>
		</isloop>

[gemini-code-assist]

For conciseness and better readability, you can use a ternary operator to assign the value to urlPrefixType.

	var urlPrefixType : String = (mode === 'LIVE') ? 'live' : 'test';