#dankfarrik-prbutton

1 messages · Page 1 of 1 (latest)

rotund rune
#

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

fickle canyon
#

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.

rotund rune
#

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? shippingaddresschange doesn'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

fickle canyon
#

Yeah no problem, let me use some visual examples instead, I appreciate you taking the time

rotund rune
#

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

fickle canyon
#

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.

rotund rune
#

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?

fickle canyon
#

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

mortal inlet
#

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?

fickle canyon
#

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.

mortal inlet
#

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.

fickle canyon
#

Thanks for consolidating, wasn't sure how you wanted to keep things organized. Yep, I'll send that momentarily.

mortal inlet
#

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.

fickle canyon
#

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

mortal inlet
#

Can you share the link so I can debug on my end?

fickle canyon
mortal inlet
#

I only have a single Standard Shipping option available.

fickle canyon
#

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

mortal inlet
#

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

fickle canyon
#

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

mortal inlet
#

No, there's no such thing as shippingOption there, so it's just ignored.

fickle canyon
#

I just misunderstood this:

mortal inlet
#

Ah, yeah, that shippingOption is the second argument being passed in to your event listener's handler.

fickle canyon
#

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

mortal inlet
#

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.

fickle canyon
#

It is! It seems all the values are properly updated

mortal inlet
#

I think it's a Chrome bug.

#

It does work properly in Safari with Apple Pay.

fickle canyon
#

Yeah, that's what's been stumping me

mortal inlet
#

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.

fickle canyon
#

Ok, that works for me for now, thanks so much for spending the time looking into it

mortal inlet
#

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.

fickle canyon
#

That sounds great, thanks again!

mortal inlet
#

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.

fickle canyon
#

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.

mortal inlet
#

Ah, interesting. It could be a bug on our end. If it is we'll find and fix it. 🙂