-
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
fix(router): mark retry payment as failure if connector_tokenization
fails
#5114
Conversation
…ry/fix-connector-tokenization
if is_retry_payment { | ||
router_data.response = Err(err); | ||
println!("failed connector tokenization"); | ||
(None, false) | ||
} else { | ||
logger::debug!(payment_method_tokenization_error=?err); | ||
(None, should_continue_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.
you can decouple this logic as it is done for access token, this function only returns the result of payment method tokenization. Rest of the decision can be taken by another function. You can try to do this.
Ok(types::PaymentMethodTokenResult { | ||
payment_method_token_result: Ok(None), | ||
is_payment_method_tokenization_performed: true, | ||
}) |
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.
should this be true? as we are not performing any tokenization in case the connector is not payme
Ok(None) | ||
Ok(types::PaymentMethodTokenResult { | ||
payment_method_token_result: Ok(None), | ||
is_payment_method_tokenization_performed: false, |
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.
the default implementation should be false right?
…ror-handling-in-cypress * 'main' of github.com:juspay/hyperswitch: fix(auth_methods): Add checks for duplicate `auth_method` in create API (#5161) chore(version): 2024.07.02.0 fix(router): rename the browser name header to `x-browser-name` (#5162) fix(router): mark retry payment as failure if `connector_tokenization` fails (#5114) fix(connector): [Paypal] dispute webhook deserialization failure (#5111) feat(analytics): Add v2 payment analytics (payment-intents analytics) (#5150) feat(globalsearch): Implement tag-based filters in global search (#5151) refactor(connector): Add amount conversion framework to iatapay along with amount conversion code to connector template (#4866) feat(payment_link): add multiple custom css support in business level (#5137) feat(connector): [Bambora Apac] Template for integration (#5062) feat(tls): add support for https in actix web (#5089) chore(ci): fix ci tests failing by removing them (#5167) chore(version): 2024.07.01.0 chore(postman): update Postman collection files ci(postman): log request id for user tests (#5159) chore(euclid_wasm): make field domain optional wasm (#5154)
Type of Change
Description
When a payment confirm call is made the status of the payment would be
requires_payment_method
while performing connector pre-processing steps. If a there is an error during this step then the status remains inrequires_payment_method
. If the pre-processing steps succeeds, the status is changed toprocessing
just before the authorize flow. Now if the status will be further updated based on the connector response.Now if there is an failure response from the connector and if the the retry feature is enabled for that merchant we go to the retry flow. Now for the chosen connector we perform the pre-processing steps, here if something fails the payment status remains in
processing
as previous during the first attempt the status was updated toprocessing
during the authorize flow.In this case if something fails in the pre-processing steps during the retry we need to fail the payment.
Additional Changes
Motivation and Context
How did you test it?
-> Create MCA of stripe with apple pay simplified flow enabled
-> The connector api in the connector tokenizatoin flow is hardcoded wrongly for test purpose. So in this case if apple pay simplified payment request is made, the error response changes to
Invalid wallet token
fromunimplemented flow
. And also in the db thepayment_intent
status will be asrequires_payment_method
.-> Configure one more connector (
BOA
) with simplified flow. And configure the routing rule such that the payment first go throughBOA
and retry happens throughStripe
.-> Enable retry for the merchant account.
-> Now I have hardcoded the
BOA
api key wrongly so that payment fails and will be retried withStripe
. Also the connector api in the connector tokenizatoin flow is hardcoded wrongly inStripe
to test if the payment reaches a terminal state (failed
) if that connector tokenization call fails for stripe.-> When made the same above request without the changes in this pr.
Checklist
cargo +nightly fmt --all
cargo clippy