-
Notifications
You must be signed in to change notification settings - Fork 1.4k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(connector): [Payme] Implement Card 3DS with sdk flow #2082
Conversation
…l to preprocessing data
label: "Apple Pay".to_string(), | ||
total_type: None, | ||
amount: amount_in_base_unit, | ||
match item.data.auth_type { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why do we need this match statement? irrespective of the auth_type we are calling generate-sale in the flow
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
it is to differentiate between the 3ds and non 3ds flow, since we are breaking at preprocessing at 3ds, we need redirection for 3ds. To show redirection we need authenticationpending status too. But in case of of non 3ds, we don't have redirection at preprocessing step, rather we move to authorize flow to complete the payment
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will not work in case of Apple Pay AuthenticationType is ThreeDs. Since Applepay is not yet supported I am approving this PR. But take this change in separate PR
label: "Apple Pay".to_string(), | ||
total_type: None, | ||
amount: amount_in_base_unit, | ||
match item.data.auth_type { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This will not work in case of Apple Pay AuthenticationType is ThreeDs. Since Applepay is not yet supported I am approving this PR. But take this change in separate PR
@@ -507,6 +587,100 @@ impl TryFrom<&types::PaymentsAuthorizeRouterData> for PayRequest { | |||
} | |||
} | |||
} | |||
#[derive(Debug, Clone, Serialize, Deserialize)] | |||
pub struct PaymePayloadData { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Rename this to PaymeRedirectResponseData. Take this in another PR
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Sure👍
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Other than that, looks good to me!
language: String, | ||
} | ||
|
||
#[derive(Debug, Serialize)] | ||
pub struct ThreeDS { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit(naming convention): ThreeDs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Raising a seperate PR to resolve this comments👍
} | ||
|
||
#[derive(Debug, Serialize)] | ||
pub enum ThreeDSType { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit(naming convention): ThreeDsType
} | ||
|
||
#[derive(Debug, Serialize)] | ||
pub struct ThreeDSSettings { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Nit(naming convention): ThreeDsSettings
@Sakilmostak Please take mine and @SanchithHegde comments in separate PR |
Type of Change
Description
Payme 3DS includes four api calls to execute payment:
i) Tokenization flow for generating
buyer_key
which contain card detailsii) Pre processing flow for generating
payme_sale_id
which contains the details of the payment requestiii) Script run on user end to generate
meta_data_jwt
iv) Pay sale call in complete authorize flow to create payment
Additional Changes
Motivation and Context
How did you test it?
Checklist
cargo +nightly fmt --all
cargo clippy