PP-11638 Add wallet path param for logging #3768
Merged
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.
Relying on getting the wallet_type from the charge when handling the authorisation result isn't reliable - as connector can return a response before it has completed authorisation, in which case the wallet_type is not present.
So stop logging the
wallet
from thewallet_type
on the charge from connector, as we can't rely on it consistently being there.Instead, add the wallet type as a path parameter for the /handle-payment-response/:chargeId path, and pass in this wallet type when passing the redirect URL back to the client-side JS in
payment-auth-request.controller.js
. We will use this for logging inhandle-auth-response.controller.js
.For now, also support the old URL without the wallet as a path parameter so we don't break in-flight payments. Support for this will be removed as a follow-up commit. We will also the logging of the wallet type in this follow-up commit. We can't add this yet, as the path parameter will not be present for in-flight payments when this change is deployed.
Rename some path params from
provider
->wallet
to avoid confusion with payment provider.Notes for reviewer
I have manually tested this locally to be sure that an in-flight walley payment that sends the user to the old
/handle-payment-response/:chargeId
route will still work, as well as a payment sending the user to the new/handle-payment-response/:wallet/:chargeId
route