#dankfarrik-prbutton
1 messages · Page 1 of 1 (latest)
hello, not sure I understand what you mean by "reset" PRButton
makes a different product selection on the page, I would like to be able to reset it to the point of requesting the shipping address again,
that is what should happen, are you seeing somethign different?
I assume you call paymentRequest.update() to update the paymetn sheet with a new amount
To be more specific, I’m initializing the paymentRequest to requestShipping, and I’m using the event for “shippingaddresschange” to hook into our site’s existing methods for creating orders and getting shipping rates. I’m wondering if there is a way to set the state of the payment request button back to where it requests the shipping address again if they hit cancel at any point.
I’m wondering if there is a way to set the state of the payment request button back to where it requests the shipping address again if they hit cancel at any point.
so I was under the impression it would do that but you're saying that it isn't, what specifically is not happening?shippingaddresschangedoesn't get triggered cause the shipping address was "pre selected" based on the older shipping address being selected, right?
are you calling paymentRequest.update() ?
I'm asking for more details so I can figure out what you're doing and what isn't working as expected
Yeah no problem, let me use some visual examples instead, I appreciate you taking the time
np
PaymentRequest Button can be tricky sometimes since it hooks into browser level APIs and Chrome can be different from Safari, so the more detail the better
It's most obvious in the PayNow window, but because I'm initializing it to "requestShipping", it looks like this when it is first opened, and it doesn't allow you to continue until the shipping address is selected:
It's this state that I'm hoping to return the window to when it gets closed. The "shippingaddresschange" event that happens once the user selects their shipping address it how I am able to integrate into the site's existing mechanisms for order creation and shipping etc.
oh sorry missed this update, reading
1/ what are you doing between the two payment request sheets opening? that part wasn't clear (cause I need to figure out how to repro)
2/
It's most obvious in the PayNow window,
what about on Safari? same issue there?
I guess I have the same question number 1, what should I be doing when the sheet is closed before it gets re-opened? The only thing I'm aware of being able to do is to update some of the values, but as far as I know that's all I can do, correct?
With this setup, once you've chosen your shipping address and close the sheet, that shipping address stays populated the next time the sheet is opened
Hello! I don't believe there's a way to reset this the way you want, as this is Chrome-specific behavior that's outside of our control.
You might be able to do it by creating an entirely new Payment Request object, but I'm curious why you would want people to have to explicitly select their shipping address again when they've already done so?
Yeah I know it seems counter-intuitive, but it's really just because I'm attempting to use that shipingaddress callback to initiate some existing things that need to happen on the page revolving around how orders are created etc on the site. Thanks for the info though, I appreciate you both looking into it. I'll just have to re-work some thing so that I can just use the usual update methods.
Hi I have another Payment Request Button question, specifically GPay. There seems to be an error where if there are multiple shipping rates available and the user selects a different one (firing the 'shippingoptionchange' event), the sheet updates, but the ui of the selected shipping rate does not change. However if you select the other shipping rate a second time, it updates the sheet again and the new rate is displayed correctly, but it never updates properly after the first selection.
Can you provide a screen recording of what you're seeing?
Or screenshots?
Make sure to redact any sensitive info.
Thanks for consolidating, wasn't sure how you wanted to keep things organized. Yep, I'll send that momentarily.
Taking a look...
Do you know what's causing the unexpected error at the beginning?
I think your code is updating the shipping rates again, so the selection reverts to the first option after the update.
Honestly no, that seems to be happening only with GPay, not ApplePay or PayNow
Interesting, here is where I'm updating the values:
ev.updateWith({
status: 'success',
total: {
amount: order.payment.amount,
label: 'Total',
pending: false
},
displayItems: [
{
amount: parseInt(order.checkout.subtotal_price.replace('.', '')),
label: "Subtotal"
},
{
amount: parseInt(order.checkout.shipping_rate.price.replace('.', '')),
label: "Shipping"
},
{
amount: parseInt(order.checkout.total_tax.replace('.', '')),
label: "Estimated Tax"
}
]
})
});```
Sorry for the poor formatting, but you can see I'm only updating the status, total, and the display items, I'm not sending shippingoptions again
I almost thought maybe I should be sending the selected shipping rate so it displayed it properly, but the other methods are working and don't require that, so I was unsure
Can you share the link so I can debug on my end?
Sure, just select one of the products and proceed to the checkout https://v20dev.getsafegrabs.io/offer-01/
I only have a single Standard Shipping option available.
Oh I'm sorry, I forgot to mention that the expedited rate is only available on the second or third bundle
Should have mentioned that
Ah...
Looking at the actual code on your site you are updating the shipping options inside your shippingoptionchange listener:
ie.on("shippingoptionchange", function(e) {
i(e.shippingOption.id, function() {
e.updateWith({
status: "success",
shippingOption: e.shippingOption,
total: {
amount: B.payment.amount,
label: "Total",
pending: !1
},
displayItems: [{
amount: parseInt(B.checkout.subtotal_price.replace(".", "")),
label: "Subtotal"
}, {
amount: parseInt(B.checkout.shipping_rate.price.replace(".", "")),
label: "Shipping"
}, {
amount: parseInt(B.checkout.total_tax.replace(".", "")),
label: "Estimated Tax"
}]
})
})
}),
But, hm.
shippingOption shouldn't be valid there, it should be shippingOptions with an s
Ah, I did test passing the shipping option through but it made no change.
Yeah, I didn't want to send all the shipping options there, I thought it might want the actual selected option passed in
No, there's no such thing as shippingOption there, so it's just ignored.
I just misunderstood this:
Ah, yeah, that shippingOption is the second argument being passed in to your event listener's handler.
Yeah, and I'm using that to send to our shipping rate functions, it was just a last ditch effort to try to get it to display the selected rate
What's interesting is that when it happens the total is actually correct for the $10 shipping option.
Even though the $6.99 option is displayed.
It is! It seems all the values are properly updated
Yeah, that's what's been stumping me
I'll see if I can reproduce this later, but for now I'm not sure what to recommend. I don't think you're doing anything wrong, exactly.
Ok, that works for me for now, thanks so much for spending the time looking into it
No problem! I need to step away, but @hearty python is around if you have other questions. I'm going to try and reproduce the bug in my own test integration later and, if I'm able to do so, we'll likely escalate the issue internally and/or to the Chrome team to get it fixed.
That sounds great, thanks again!
Jumping in for a quick update: I was able to reproduce this in my own test integration. We're investigating further, but it's more likely this is a Chrome bug and much less likely you're doing anything wrong on your end.
Thanks for continuing to look into it! I actually tested it on a Shopify store, and Shopify appears to be integrating GPay using Google's sdk directly and did not seem to have the same issue, so I was still a bit concerned.
Ah, interesting. It could be a bug on our end. If it is we'll find and fix it. 🙂