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 in requires_payment_method. If the pre-processing steps succeeds, the status is changed to processing 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 to processing 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
[ ] This PR modifies the API contract
[ ] This PR modifies the database schema
[ ] This PR modifies application configuration/environment variables
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 from unimplemented flow. And also in the db the payment_intent status will be as requires_payment_method.
-> Configure one more connector (BOA) with simplified flow. And configure the routing rule such that the payment first go through BOA and retry happens through Stripe.
-> Now I have hardcoded the BOA api key wrongly so that payment fails and will be retried with Stripe. Also the connector api in the connector tokenizatoin flow is hardcoded wrongly in Stripe to test if the payment reaches a terminal state (failed) if that connector tokenization call fails for stripe.
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