braintree-web
braintree-web copied to clipboard
onShippingChange clarity
This is a follow up to #470
In that issue, @crookedneighbor mentioned that actions.order.patch([
would not work in the onShippingChange
callback. However, with limited testing, I was able to get it to work just fine as far as representing the change within the paypal modal popup. So, I'm not sure if I'm misunderstanding here (perhaps it appears to work fine, but in some production mode, or on the braintree side, it doesn't work?), or if there is more to understand here?
The desired use case is to have the paypal modal be able to:
- change shippingOptions based on addressChange
- change
amount
(total) based on selected shippingOptions due to changes in tax and shipping * charges
Is this possible?
I may be misunderstanding what actions.order.patch
does under the hood, but I thought it was an API call to the v2 orders API, which as far as I knew wasn't supported by Braintree. I'll reach out to my colleagues that work on the PayPal SDK and get some clarification around it.
Upon further testing, it appears the onShippingChange only takes affect after the initial order creation. That is, the onShippingChange handler fires in the following cases, all of which you would expect:
- Initial paypal modal load (or after login if user is not logged into paypal)
- change in
selected
within shippingOptions - change in ship to address
However, only in the 3rd case does the "total" actually updated within the paypal modal. Case 1 doesn't reflect the order patch, and case 2 instead adds the total from the shipOption to the amount
, which is incorrect, and case 3 does correctly update the ship
There appears to be some circumstances in which case 3 will still not work, such as when going "back" to the original shipping address that was used on the first load of the modal, it won't reflect the order patch, but instead use the original amount in the order.
So, I believe this is what is meant by "Braintree doesn't support actions.order.patch
"... it has unexpected/non-working behavior!
It would be good to see what it takes to get this behavior working concretely, it would be a huge benefit to simplify the paypal integration with braintree (no more reason to come back to a confirm page on the client side), as well as obviously improve conversion.
Any more solid/concrete information on having this work?
To be clear, the order.patch I am issuing as a test is:
actions.order.patch([
{
op: 'replace',
path: '/purchase_units/@reference_id==\'default\'/amount',
value: {
currency_code: 'USD',
value: 99,
}
}
]);
simply the amount
Ideally, there would be a way to update shipOptions
as well, which there may be, but I haven't found out how to do that yet.
@crookedneighbor any update on what's possible with braintree + paypal in regards to changing the order totals when the shipping address is changed, and also changing the ShipOptions in the same scenario?
Sorry for the delay. No updates, but I've passed this issue onto the team responsible for communicating with the PayPal APIs.
Hi @crookedneighbor,
Any update here? I think that such a feature would prove invaluable to the paypal/braintree ecosystem. I mean we're talking about a whole entire less page on conversion here, and the ability to close the order within the paypal flow, which would be huge.
I'll happily annoy/request the proper team responsible for this implementation if they have an open channel somewhere?
Thank you for your time.
I've pinged the team responsible for this. Will post here if there's any updates.
I've confirmed that it's on the roadmap, but there is not yet an ETA for when the work will be completed.
@crookedneighbor Any updates on this feature?
No updates right now, but I'll ping the team responsible for the feature again.
@crookedneighbor Hello! We're coming up on a year later for support for this, any word? I am trying, without success, to use something like
onShippingChange(data, actions) {
return actions.order.patch([
{
op: 'replace',
path: '/purchase_units/@reference_id==\'default\'/shipping/options',
value: [
{
id: 'shipping-speed-fast',
type: 'SHIPPING',
label: '22222 Shipping',
selected: true,
amount: {
value: '2.00',
currency: 'USD',
},
},
{
id: 'shipping-speed-slow',
type: 'SHIPPING',
label: '1111 Shipping',
selected: false,
amount: {
value: '1.00',
currency: 'USD',
},
},
],
},
]);
},
and paypal doesn't seem to like that, giving an error of UNPROCESSABLE_ENTITY. At one point, someone mentioned braintree creating orders using v1 instead of v2 paypal may be the culprit, but I don't really know how to investigate that, since paypal documentation is a wilderness of confusion.
Thanks for any support.
Braintree has plans to update our internal API to use the v2 PayPal orders API, but it is not available yet, and there is no timeline for it.
Thanks. Seems like the v2 api has been out since Feb of 2019 (https://medium.com/paypal-engineering/launch-v2-paypal-checkout-apis-45435398b987). Any word on this front?
No updates at this time.
Any update on this this I would like to be able to allow customers to checkout with out going back to our site to confirm.
There are still no updates on this.
@719media did you find a workaround for this that didn't involve redesigning your checkout?
@crookedneighbor any updates on this. it's been like 3 years since paypal launched v2. This is incredibly important to integrate for my merchants. I can patch the total but it's not reliable and my sandbox throws me errors about permission denied. Not sure if this will just auto fail in production. Seems patching shipping options is not supported at all still. Is it possible to patch server side or something
@cwarkentin I've passed on your comment to the team responsible for our API integration with PayPal and will let you know what they say.
Sorry for the long delay, but I finally did get confirmation that supporting the shipping callback is on the roadmap for this year. We will definitely update this issue when it is supported.
@crookedneighbor any updates on this. it's been like 3 years since paypal launched v2. This is incredibly important to integrate for my merchants. I can patch the total but it's not reliable and my sandbox throws me errors about permission denied. Not sure if this will just auto fail in production. Seems patching shipping options is not supported at all still. Is it possible to patch server side or something
@crookedneighbor Are you able to confirm if patching the total amount will work in production? I'm getting the same errors as @cwarkentin. Thank you.
Thanks for putting this on the roadmap! These updates may unblock a handful of checkout optimizations we'd like to do on our Braintree integration.
Thanks for putting this on the roadmap, would be great to have this soon. This is definitely a huge blocker in the Braintree/Paypal flow for us
@crookedneighbor I have noticed that onShippingChange
works if I call createOrder
using the Paypal API directly with actions.order.create
.
However, I wonder if it would work to tokenize the Paypal data that comes in onApprove
callback using the checkout instance from Braintree as before. Thus I don't need to change anything else in the code, specially in the backend
@jortizsao I have noticed the same. The following does not currently work, but here is where I'm at:
In createOrder
, if I sidestep Braintree and use actions.order.create({...})
instead of instance.createPayment({...})
, I'm able to load a PayPal modal with its expected functionality (including correct behavior for onShippingChange
).
Next, I attempt to authorize the order, hooking into Braintree instance.tokenizePayment
to obtain a payment method nonce:
onApprove = (data, actions) => {
// Authorize or capture to obtain the order's details
actions.order.authorize().then((authorizePayload) => {
/**
* The values `data.billingToken` and/or `data.paymentID` are necessary for Braintree
* tokenization to work as expected. Because we're using `actions.order.create`
* from PayPal SDK v2 instead of `instance.createPayment` from Braintree and v1,
* those values return as empty strings.
*/
instance.tokenizePayment(data).then((tokenizePayload) => {
// When used during `gateway.transaction.sale` in backend, the value in
// tokenizePayload.nonce triggers "Incomplete PayPal account information" error.
});
});
}
Unfortunately, running gateway.transaction.sale()
on the backend using the nonce generated by tokenizePayment
returns an error 82901. Perhaps I need to include facilitatorAccessToken
in some form.
TL;DR:
- Braintree uses Paypal Orders API v1 to perform tokenization, but
actions.order.create
is part of Orders API v2 (slight edit to language here) - Using
onShippingChange
sorta works, but shipping won't be added to the line item total on first modal load, and changing shipping option triggers aPATCH
error.
Yes @shawncook, I'm also stuck in the same issue
@crookedneighbor hi, any update on this issue for those of us eager to address this problem? I have a small hope that you're busy about to drop v4 of this library with all sorts of improvements including this, as activity seems to have been silent lately. Thanks!
No updates as of yet. Y'all will be the first to know when this has been fixed :)
Hey, some more month have passed. Any new Updates? Is it now possible to change shipping Option with Braintree integration or can you provide at least any working Workaround?
@crookedneighbor any updates here? It does seem very strange/unexpected/baffling that the new paypal v2 has been out for almost 4 years now, and braintree, the company we went with specifically for their first-party paypal support, still doesn't support it. I mean no offense, I'm just surprised that this hasn't been a higher initiative. Perhaps there are reasons that may help us understand why this continues to be backburnered? Should we look into just implementing paypal integration outside of braintree?