fix: Update Stripe DPM check in handle_processor_response #4158
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
julianajlk
changed the title
julianajlk
force-pushed
the
julianajlk/REV-4019/stripe-dpm-handle-response-attribute
branch
from
bfe3bea
to
61c055c
Compare
christopappas
approved these changes
May 8, 2024
julianajlk
deleted the
julianajlk/REV-4019/stripe-dpm-handle-response-attribute
branch
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
REV-4019.
Locally, this is the data sent from the MFE
{'payment_intent_id': 'pi_3PC2r5H4caH7G0X10gjfcFiy', 'skus': '8CF08E5', 'dynamic_payment_methods_enabled': 'true'}With content sent from the MFE as
application/x-www-form-urlencoded, the Javascript boolean will be converted to a string representation of true/false in the backend, but we're having unexpected results, always evaluating to False.I am removing the boolean conversion for this check and adding logs. I don't see an issue with this since on the
assert status == 'succeeded'it will error if the status is anything other thansucceededor in the previous check'requires_action'. This was added initially as a guard to prevent from getting into the DPM flow while the experiment is off.