Merge branch 'introduce-new-decide-flow-complete-authorize' into call-ucs-for-pre-authentication-in-authorize

This commit is contained in:
Hrithikesh
2025-10-24 11:41:16 +05:30
committed by GitHub
2 changed files with 0 additions and 50 deletions

View File

@ -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>;

View File

@ -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.