v6 - Synchronous submit with order tracking #2425
Merged
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
|
size-limit report 📦
|
|
Size Change: +5.68 kB (+1%) Total Size: 1.12 MB
ℹ️ View Unchanged
|
|
…tures in 3DS2 and Card
ribeiroguilherme
commented
Feb 5, 2024
Comment on lines
+70
to
+85
| onSubmit: (state, component) => { | ||
| return makePayment(state.data) | ||
| .then(response => { | ||
| if (response.action) { | ||
| component.handleAction(response.action); | ||
| } else if (response?.resultCode && checkPaymentResult(response.resultCode)) { | ||
| alert(response.resultCode); | ||
| } else { | ||
| // Try handling the decline flow | ||
| // This will redirect the shopper to select another payment method | ||
| component.handleDeclineFlow(); | ||
| } | ||
| }) | ||
| .catch(error => { | ||
| throw Error(error); | ||
| }); |
There was a problem hiding this comment.
@m1aw It is still using the old syntax for the onSubmit: handling action part with component.handleAction; checking the resultCode manually instead of passing back to the library; I believe it also does not trigger the new callbacks onPaymentCompleted/onPaymentFailed. The goal is to make it work with the new syntax at least (onSubmit(state, component, actions)), so all payment methods follow the new flow.
Perhaps this needs an adjustment like it was done with GooglePay/ApplePay, as it seems that AmazonPay has an special flow to decline the payment (component.handleDeclineFlow)
Would that be possible?
There was a problem hiding this comment.
To the first part. I have changed it to use actions.resolve as part of the tests. I will pull those changes in.
On the second part, I have not made modifications to the way AmazonPay onSubmit works and also the way handleDeclineFlow works.
I thought that was the objective, not make more changes then the ones necessary here. I will take a look to also adjust it, I because I think I misunderstood it.
There was a problem hiding this comment.
Adjusting the callback to behave in the new way is a necessary one I'd say. We don't want merchants to have to implement two different submit flows depending on the payment method that they use.
Let's then merge this PR as it is blocking other tasks, and then you can iterate on this in a new PR along with the e2e tests.
ribeiroguilherme
changed the title
ribeiroguilherme
requested review from
marcperez,
pabloai,
sponglord and
longyulongyu
as code owners
sponglord
approved these changes
Feb 6, 2024
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.
Summary
onSubmit/onAdditionalDetails requires data to be passed back
The payments response data must be passed back to the lib. Internally we handle the action; trigger the Partial payment flow; or check the payload and decide if the payment is completed or not.
onPaymentCompleted and onPaymentFailed
To have more granular control of what is happening:
onPaymentCompletedis called when the payment is successfullonPaymentFailed(new callback) is called when the payment failsPartial payments
onOrderCreatedrenamed toonOrderUpdatedto be more conciseonPaymentMethodsRequestwhich is triggered when there is a partial order pending. The merchant then can request the new payment methods in order to update the UI accordinglyonAuthorized
onAuthorized now is triggered before the 'onSubmit' . It returns an object with the authorizedEvent (raw data from ApplePay/GooglePay/PayPal) along with the formatted billingAddress and deliveryAddress.
onAuthorizedmust be resolved in order to trigger the payment flow (onSubmit)onAuthorizedfor Paypal happens before the onAdditionalDetails, as the authorization data is available at that pointApplePay onOrderTracking
Adding support for ApplePay order tracking.
onOrderTrackingRequestcallback is available. If it is, it is called and then the merchant must create and pass the order details back to the Component.AVS improvements for GooglePay and ApplePay
If the information about the billing address and shipping address is available in the GooglePay/Applepay components when the authorization happens, we populate the
state.datawith the billingAddress and deliveryAddress fields. This improves the AVS checks.ApplePay improvements
If the payment fails during the
onSubmitcall, or if the merchant rejects the payment during theonAuthorizedcallback, the ApplePay payment overlay will display 'Payment Failed' messageThe error can also be customized in the 'onSubmit' by doing:
or in the
onAuthorizedby doing:GooglePay improvements
If the payment fails during the
onSubmitcall, or if the merchant rejects the payment during theonAuthorizedcallback, the GooglePay overlay will display 'Payment Failed' message.The error can also be customized in the 'onSubmit' by doing:
or in the
onAuthorizedby doing:WIP:
onErrorcallback .(Align with CoreonError)Tested scenarios
Fixed issue: