mirror of
https://github.com/juspay/hyperswitch.git
synced 2025-10-28 04:04:55 +08:00
Merge branch 'introduce-new-decide-flow-complete-authorize' into call-ucs-for-pre-authentication-in-authorize
This commit is contained in:
@ -654,39 +654,12 @@ pub struct PaymentsAuthenticateData {
|
||||
pub amount: Option<i64>,
|
||||
pub email: Option<pii::Email>,
|
||||
pub currency: Option<storage_enums::Currency>,
|
||||
// pub payment_method_type: Option<storage_enums::PaymentMethodType>,
|
||||
// pub router_return_url: Option<String>,
|
||||
pub complete_authorize_url: Option<String>,
|
||||
pub browser_info: Option<BrowserInformation>,
|
||||
// pub connector_transaction_id: Option<String>,
|
||||
// pub enrolled_for_3ds: bool,
|
||||
pub redirect_response: Option<CompleteAuthorizeRedirectResponse>,
|
||||
|
||||
// New amount for amount frame work
|
||||
pub minor_amount: Option<MinorUnit>,
|
||||
}
|
||||
|
||||
impl TryFrom<PaymentsAuthorizeData> for PaymentsAuthenticateData {
|
||||
type Error = error_stack::Report<ApiErrorResponse>;
|
||||
|
||||
fn try_from(data: PaymentsAuthorizeData) -> Result<Self, Self::Error> {
|
||||
Ok(Self {
|
||||
payment_method_data: Some(data.payment_method_data),
|
||||
amount: Some(data.amount),
|
||||
minor_amount: Some(data.minor_amount),
|
||||
email: data.email,
|
||||
currency: Some(data.currency),
|
||||
// payment_method_type: data.payment_method_type,
|
||||
// router_return_url: data.router_return_url,
|
||||
complete_authorize_url: data.complete_authorize_url,
|
||||
browser_info: data.browser_info,
|
||||
// connector_transaction_id: None,
|
||||
redirect_response: None,
|
||||
// enrolled_for_3ds: data.enrolled_for_3ds,
|
||||
})
|
||||
}
|
||||
}
|
||||
|
||||
impl TryFrom<CompleteAuthorizeData> for PaymentsAuthenticateData {
|
||||
type Error = error_stack::Report<ApiErrorResponse>;
|
||||
|
||||
|
||||
@ -1,23 +0,0 @@
|
||||
Currently in hyperswitch, under authorize flow, there can be a lot of flows that must be called before actually calling the authorize. Like session/access token, customer create, order create etc.
|
||||
Currently these are scattered all across the handler function 'pub async fn payments_operation_core<F, Req, Op, FData, D>(' .
|
||||
I want to standardize the flows like this.
|
||||
|
||||
PrimaryFlows and Secondary Flows.
|
||||
PrimaryFlows: The actual flow.
|
||||
SecondaryFlow: These flows might come as prerequisites before the Primary Flows. There can be multiple Secondary Flows for a PrimaryFlow.
|
||||
|
||||
PrimaryFlows can be defined as:
|
||||
1. A flow where the response is returned to the client.
|
||||
Eg: Authorize, Capture
|
||||
Authorize can have SessionToken, OrderCreate etc.
|
||||
|
||||
If Authorize is a PrimaryFlow, Then SessionTokena and OrderCreate will be SecondaryFlow.
|
||||
The order will be like SessionToken(2ndary) -> OrderCreate(2ndary) -> Authorize(Primary).
|
||||
Similarly,
|
||||
* SessionToken(2ndary) -> PreAuthN(Primary).
|
||||
* SessionToken(2ndary) -> AuthN(Primary).
|
||||
* PostAuthN(2ndary) -> Authorization(Primary)
|
||||
|
||||
Lets have marker trait for Primary and Secondary Flows. Feel free to come up with a better nomenclature for things.
|
||||
|
||||
Execution order must be known at compile time.
|
||||
Reference in New Issue
Block a user