Add IRIS payment component #3708
Conversation
🦋 Changeset detectedLatest commit: 15be82f The changes in this PR will be included in the next version bump. This PR includes changesets to release 1 package
Not sure what this means? Click here to learn what changesets are. Click here if you're a maintainer who wants to add another changeset to this PR |
✅ Deploy Preview for adyen-web ready!
To edit notification comments on pull requests, go to your Netlify project configuration. |
Summary of ChangesHello @johnayeni, I'm Gemini Code Assist1! 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 introduces the Highlights
Using Gemini Code AssistThe 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
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 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
|
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
The pull request introduces a new Iris payment component, including its Storybook configuration and integration into the existing component structure. The changes involve adding new files for the Iris component, updating the TxVariants enum, and exporting the new component. A significant change was made to the IssuerListContainer.tsx file, specifically to the isValid getter, which now unconditionally returns true. This change needs careful consideration as it bypasses the intended validation logic for components extending IssuerListContainer.
packages/lib/src/components/helpers/IssuerListContainer/IssuerListContainer.tsx
Show resolved
Hide resolved
size-limit report 📦
|
|
/gemini review |
There was a problem hiding this comment.
Code Review
This pull request introduces the new Iris payment component, which is a significant and well-executed addition. The implementation is robust, featuring two distinct modes (Bank List and QR Code) with a responsive default based on the device type. The changes are thoroughly supported by a comprehensive suite of Storybook stories, unit tests, and end-to-end accessibility tests, which is excellent. I also appreciate the thoughtful refactoring of existing components like IssuerListContainer and the creation of the reusable SegmentedControlRegion to improve type safety and accessibility. My feedback includes a minor suggestion to improve module organization for cleaner imports.
ScottiBR
force-pushed
the
add-iris-payment-component
branch
from
0990430 to
97917a6
Compare
…d validate contract before fowarding to the component
johnayeni
requested review from
ScottiBR,
m1aw and
ribeiroguilherme
and removed request for
ScottiBR
packages/lib/src/components/Iris/components/IrisComponent.module.scss
Outdated
Show resolved
Hide resolved
|
|
||
| // Select an issuer from the dropdown (opens the listbox) | ||
| await iris.selectIssuerOnSelectorDropdown('Piraeus Bank'); | ||
| await iris.pay(); |
There was a problem hiding this comment.
Are we sure that the interceptAndValidatePaymentResponse() is being executed and performing its assertions right after the await iris.pay() is called?
Asking because it seems weird by reading the code . I would expect to see the assertions of the payments response right after the payment step, but they are added as first thing in the function block. Feels like they might be ignored.
There was a problem hiding this comment.
The assertions do run page.route() sets up an interceptor that fires when the request is made during iris.pay(). So the callback executes at the right time.
However, you raise a valid concern: if the request never happens, the test would pass silently with no assertions executed.
| /** | ||
| * Number of milliseconds that the component will switch to throttled mode | ||
| */ | ||
| throttleTime?: number; |
There was a problem hiding this comment.
Maybe we add in the JSDoc what is the default value of these fields
| @@ -0,0 +1,15 @@ | |||
| import { IssuerListConfiguration, QRLoaderConfiguration } from '../types'; | |||
|
|
|||
| export type IrisConfiguration = IssuerListConfiguration & Pick<QRLoaderConfiguration, 'countdownTime' | 'qrCodeData' | 'paymentData' | 'delay'>; | |||
There was a problem hiding this comment.
Is it expected to not expose the throttleTime and throttleInterval?
There was a problem hiding this comment.
Yes, that is intentional. We decided to handle the throttleTime and throttleInterval exports in a separate PR, similar to how we managed the recent onKeyPress fix.
This approach allows us to keep this PR focused while we refine the logic for other payment methods. Specifically, we want to ensure we implement guardrails, such as enforcing a minimum throttle interval and validating related props, before exposing them to the public API.
| export interface IrisData { | ||
| paymentMethod: { | ||
| type: string; | ||
| issuer?: string; | ||
| }; | ||
| } | ||
|
|
||
| export enum IrisMode { | ||
| QR_CODE = 'qrCode', | ||
| BANK_LIST = 'bankList' | ||
| } |
There was a problem hiding this comment.
This types will be exposed in the public typescript definitions, although they are not needed to be there.
Perhaps add a description marking them as @internal and we add this feature in the near future , or move these types to a different file.
| export { default as BillDeskWallet } from './BillDesk/BillDeskWallet'; | ||
| export { default as Dotpay } from './Dotpay'; // add other tx variants | ||
| export { default as EPS } from './EPS'; | ||
| export { default as Iris } from './Iris'; |
There was a problem hiding this comment.
component-map.ts and component-name-map.ts files.
| }, [props.setComponentRef, irisRef.current]); | ||
|
|
||
| useEffect(() => { | ||
| if (!props.issuers.length) { |
There was a problem hiding this comment.
Is it even possible that the issuer list is empty when using this payment method ?
If that is not the case, I would rather not add custom logic for this scenario. That also simplifies upstream on Iris.tsx where we are checking a boolean flag to know if analytic events need to be sent or not.
| } | ||
|
|
||
| export const SegmentedControlRegion = ({ id, ariaLabelledBy, className, children }: SegmentedControlRegionProps) => { | ||
| return ( |
There was a problem hiding this comment.
There is a sonarcloud issue about this specific div . Is it something that we need to look into?
|
4 participants
📋 Pull Request Checklist
📝 Summary
IRIS Payment is a real-time bank transfer system, popular in Greece, allowing direct payments from a customer's bank account via their mobile banking app, often by scanning a QR code or by selecting an bank issuer to be redirected to. This PR adds proper support for this Payment method to the SDK.
🧪 Tested scenarios
Both the redirect flow and the qr code flow for the IRIS payment method have been covered by the following tests
🔗 Related GitHub Issue / Internal Ticket number
COSDK-861
Closes: