#phonicuk-payment-event
dreamy tundra
Hi 👋 I don't believe so but would need to confirm. Is this behavior that you're currently seeing?
turbid gust
I'm not sure yet - I just this second had to refund a payment just now because they didn't supply a postal code and our system expected that as a field so it was more a question of whether or not I need to tweak something since I don't know if it's going to keep trying (yet) - if it won't keep trying then no biggie.
Similarly, is there any information on which fields I'm guaranteed to get in a customers address? I really wasn't expecting an order without a postal code to even be valid.
dreamy tundra
Gotcha, I'll work on setting up a test on the side (but the channel is a bit busy so that may take me a couple minutes).
What parts of your flow are collecting customer address information and how?
turbid gust
We're using payment links - so all data collection is stripe side.
And all the processing is webhook driven
dreamy tundra
Do you have the ID of a Payment Link (plink_XXX) where you saw it not collect an address?
turbid gust
pi_3KthffHd51xGsopZ1MwvWmYt
err sec sorry not what you asked for xD
plink_1Kp8snHd51xGsopZzFyPgCDH
that pi is the associated intent though, where it didn't collect a postal code or anything that really resembled a valid address
dreamy tundra
Hm, and I was just able to reproduce that as well when I selected Thailand as the country.
turbid gust
Interesting.
I was wondering if it was one of those "Technically this country doesn't use them" but google says they use them same as anyone else.
dreamy tundra
Unfortunately I don't have enough context on their addresses to know off the top of my head whether that's a valid scenario. I'm going to poke on some other countries in that flow and see what happens.
turbid gust
I'm slightly concerned that if the postal code isn't validated against the payment details then we can't guarantee that we've met our know-your-customer requirements RE tax/vat etc. In this situation I just refunded and asked the customer to provide full information but it's weird that they were allowed to omit a postal code in the first place.
I suspect it may have something to do with the fact that it was a pre-paid card though.
ordinarily though I'd expect a postal code to be one of those "if you're collecting billing addresses you're guaranteed to have it" even if the customer just went and typed in all zeros.
Interestingly, the postal_code was null rather than empty string too.
So something is wrong 😅
dreamy tundra
I would expect that value to be null if no value was provided.
My suspicion is that we don't have those set as required address fields for those countries, but am looking for supporting documentation on that.
It looks like for Thailand that we only require Line 1 and City.
dreamy tundra
Not that I've found so far (my observation was based on what fields were being flagged as required when I tried to check out without providing address information.)
turbid gust
gotcha
So the question becomes if this is intentional and there's some quirk of TH addresses that means that it's not required, or if it's a bug/oversight and it should be asked for.
dreamy tundra
Agreed, and from my testing I saw similar behavior for Uruguay. My (possibly naive) hunch is that since the countries are smaller, that they're less likely to have duplicate city names so city+line_! would be enough to identify a specific location.
turbid gust
makes sense from that perspective, at which point integrators need to be made aware that an address doesn't necessarily have a postal code - or the fact that it's not technically required for the card validation doesn't mean it should be optional as a field.
Where "Information we need to process the payment" and "Information the vendor is expecting" don't necessarily match
dreamy tundra
Agree it can be a bit confusing as a billing address isn't required for processing card payments.
turbid gust
gotcha
dreamy tundra
I'm checking in with my colleagues to see if any of them know if the address requirements for various countries are documented anywhere.
turbid gust
Regardless it is something I'd normally expect to have whenever "Collect billing addresses" is turned on unless explicitly documented otherwise.
I can't rightfully imagine that "bangkok, TH, bangkok" should be allowed through as a valid address normally 😂
dreamy tundra
Completely understand, I pulled up that intent and immediately started scratching my head as well.
I also tried collecting shipping address to see if that had more strict requirements, but it seems to mirror the billing address criteria.
My colleagues weren't able to locate any documentation either. I'm sorry that we weren't able to provide that, but I am submitting your feedback to our teams about the pain point that this created for you.
turbid gust
👍
for now I've just put in a path to try and accommodate this so we'll manage - just a weird one to have come up!
fast umbra
For some explanation of this: https://stripe.com/docs/disputes/prevention/verification#avs-check
and you can see on each charge whether the check was performed by the bank:
https://stripe.com/docs/api/charges/object#charge_object-payment_method_details-card-checks-address_postal_code_check
turbid gust
gotcha
Stands to reason that pre-paid cards might pass in circumstances where regular ones don't too
fast umbra
That i really don't know, you'd likely want to reach out to our support team with specific examples for them to help you look at ( https://support.stripe.com/contact )
turbid gust
👍 So far this just seems to be a one-time thing so I'm really not that bothered - it was more a question of what adjustments I need on our end and what the actual cause was etc.
We're only recently moving things over to stripe so I could have imagined that postal codes were never required for example and it was just luck that everyone provided them
but it seems this is an edge case so I'll just work around that rather than assuming that I don't have postal codes
cheers for your help chaps 🙂