Hide Stripe Postcode / Zipcode field and use Ubercart billing address details instead

You're welcome. :-)

Thanks for pointing out this zip code fix! I'll update the ticket once It's in dev.

I've just installed the 7.x-3.x version on a dev site, and it works great. But I did hit this zip code requirement.

Is there any way, instead of defaulting the stripe zip form field to be the one already entered, we can go the whole way and hide the stripe one? There's already the warning that the billing address and the card address must match, but that also becomes confusing if there are two address entries that may not necessarily match.

I also noticed that the stripe zip field required at digit number to validate. But I'm in the UK where post codes are not in that format. So I could only get the order and payment to go through if I made up a zip code. That'll work fine for stripe test cards, but I clearly can't have customers know that they have to invent a zip code to validate the form on a live site, and even then stripe would probably rightly reject the payment because the billing address is wrong.

Is there any scenario when doing that could backfire and a card payment could fail because the zip field is hidden?

Also, will it work to populate the zip field with the ubercart billing address one when the billing address contains something other than a 5 digit zip code, or will it fail validation as it does when the field is visible?

Nice. I didn't realise that 4242 test card was us specific, nor that stripe sets the expected format of the zip to match the billing country of the card. Try with a UK card, and the form changes to say "postcode" and accepts a UK formatted one.

In which case, as long as it can't backfire, simply hiding stripe's zip field should fix this issue.

Changing issue name

Hiding the Stripe Elements zip/postal code field seems like it will work. It still needs to be passed from the ubercart field to stripe though.

Stripe docs say:

If you are already collecting your customer’s billing postal code elsewhere on your checkout page, we recommend including it as part of owner and hiding the Elements postal code field—set the Element option of hidePostalCode to true.

https://stripe.com/docs/sources/cards#create-source

If a site only collects zip code in the Stripe Element then they would have to add a billing zip/postal code field to the billing address section.

One solution can be:
Add a uc_stripe settings checkbox that says something like:
"Collect zip/postal code with stripe credit card details. If disabled, the billing zip code will automatically be passed to stripe for each order"

Just read #11 and #12

cebab54, #11 and #12 in which issue? (You're #12 in this issue, so I don't quite follow what you're saying)

@Collins405, I tried the snippet in post #2 (planning to try #5 once I'd got that working, then generate a patch for others here to review).

After replacing the existing line with those in your snippet, the checkout page just shows

Sorry, for security reasons your card cannot be processed. Please refresh this page and try again. If the problem persists please check that Javascript is enabled your browser.

Did you try what you suggested in #2? If so, any chance you could upload a patch file to this issue so I can make sure I used your code correctly. I've obviously done something wrong.

There is nothing in the Stripe dashboard because it didn't get that far. The message I quoted is displayed in the checkout page where you should see the fields to enter card number etc, if the JavaScript to create that subform was working.

Here's the change I made to replicate what you described at#2. What have I done wrong?

TIA

I've found why it's not working.

If I remove the code that adds the event listener, it works fine. So I tried changing the function that runs when the change event fires, to something trivial, but it still wouldn't work. So I inserted debug code to inspect the variable myPostalCodeField. It's null.

So calling myPostalCodeField.addEventListener fails, which means the stripe element is never inserted into the page, which is why it displays a stock error instead.

So now we need to figure out why myPostalCodeField is null for some sites but works fine for yours. Therein lies the bug.

I think the culprit is this checkbox: "My billing information is the same as my delivery information."

Until that is cleared, the form elements aren't created for the billing address. That's why the code that populates the stripe zip from the ubercart billing one does nothing, and the command to attach listeners fails.

But it also complicates the logic of what we're seeking to do. We want to send stripe the postal code of either the delivery or billing address, depending. To do that this way, we need change event listeners on the delivery postcode, the checkbox, and the billing postcode textbox at the point when it's created. That last bit is tricky, which makes me wonder if listening to change events is the right approach. I haven't properly digested all the Stripe docs. Is it possible to update the card element just before submission and set the postal code then? If so, we hide it as per #5, then set the postal code at form submission time.

See around line 1074 of uc_stripe.module
'postal_code' => @$order->delivery_postal_code

The delivery postal code is saved to orders, it's possible the billing zip is saved as well.

When the synchronous submission of the embedded Stripe form takes place, and the billing postcode for the order is passed to stripe, would we have access to properties of the server-side order object to use that?

Sorry, meant asynchronous. Mistyped on phone

For me, users having to enter their billing address postcode twice is confusing enough that I'd like to hold off upgrading to 7.x-3.x until we've fixed it so they don't have to do so. But it seems I'm talking to myself in this issue now, and nobody else is suitably bothered by this to work on it. The 7.x-2.x branch has recently been marked unsupported.

How are other site administrators viewing this?

Hey @JamesOakley,

Sorry for late response. The module passes paymentMethod id to the server side. Future api calls can be done with that ID. You can retrieve the information using the id as well.

Taking the approach of hiding the zip code field would mean that, we would have to make an update API call server side to add in the billing zip code before the actual charge.

Regarding the JS only approach, I continued the work from @collins405 and fixed the bug you noticed, this patch updates it via JS and watches the checkbox as well as billing and delivery zip codes.

Whoops, here is the patch.

Hi Andrae

That's working a lot better.

On not hiding the postcode field, I can see from trying that it's a lot less confusing once the postcode field comes prepopulated with the one set in the address panes above.

I tried making various changes to the checkbox and the two zip codes. These 4 worked.

1. With the checkbox ticked, the postcode is correctly copied into the Stripe embedded form.
2. With the checkbox still ticked, if you change the delivery address postcode the Stripe postcode also updates.
3. If you untick the checkbox, and change the delivery address, the Stripe postcode correctly stays the same - the new delivery address is not relevant because it is now the billing address that matters.
4. If you then recheck the checkbox, the changed delivery address postcode is then correctly copied into the Stripe postcode form.

The only one I couldn't get to work, is this:

5. Clear the checkbox, and change the billing address postcode. Expected behaviour: The postcode in the Stripe form should update to the newly entered postcode. Actual behaviour: It doesn't update.

Apart from that one scenario, the postcode in the Stripe form now stays in sync with that in the billing / delivery addresses.

Thanks again for working on this.

@JamesOakley

Thanks for testing it, i'll take a closer look at your scenario 5.

If you want to take a stab at fixing it please go ahead.

Anyone still working on this fix? Would be nice to have.. :)