#korra-applepay-phonenumber
random igloo
👋 @tired ibex let's talk here please
tired ibex
And we are back!
random igloo
So I read your other messages but I don't fully grasp the issue. Where are we stripping and where is it not appearing?
tired ibex
Given that a user selects apple pay as their payment method at checkout, the phone number that appears on the customer is stripped of country code
random igloo
Is this a Dashboard only issue?
tired ibex
This data is passed down stream to our authentication system which creates a user with bad phone number data
random igloo
can you give me a clear example Customer id to look at?
tired ibex
Will you be able to see logs on the history of that user? I was in a bug bash and resolving expereince breaks with manual updates so the two example users I have have been updated to correct them
I can ask one of our test users to create a freshy if we need it
--> Test user creating another apple pay user so we have a clean example <-- hold please
random igloo
korra-applepay-phonenumber
tired ibex
here is a customer with the issue: https://dashboard.stripe.com/customers/cus_O2wsj14twmhbS2
I have one more coming from a diff tester
Here is one created just now with apple pay from a test user
tired ibex
that's right
user selects the sub from the pricing page, selects apple pay, completes transaction
random igloo
yeah that's weird, let me dig
tired ibex
There is no manual entry of phone data
random igloo
you do have phone number collection enabled at least, let me try this for a bit
tired ibex
be my guest
The challenge for us is we can't enable apple pay as a payment method util this issue is resolved. That's not great for revenue on subscription launch. 🙂
The CEO and I are in a discussion about this being a launch blocker for the Subscription line of business
random igloo
gotcha
tired ibex
We have an alpha population of about 45k people on the waitlist for subscription.
random igloo
Is this Apple Pay specific or same thing with Google Pay?
tired ibex
nope google pay works just fine
random igloo
perfect okay let me compare the 3
okay so I tried normal phone, google pay and Apple. I see the first 2 have the +1 for me and the latter on Checkout has no prefix. But it doesn't put the "wrong" prefix for me at least
So trying to figure out where the wrong prefix came from for you
tired ibex
It doesn't look like its doing wrong prefix but stripping the +1 and then misplacing the remaining digets
random igloo
the Customer you shared earlier has +31 though
random igloo
https://dashboard.stripe.com/customers/cus_O2xqHVp7BHZJUx
no the one you shared here
tired ibex
1-310
random igloo
yeah that one has +31
I just don't get where that's coming from. When I try Apple Pay I get a number with no prefix at all
tired ibex
LA area code mis parsed
random igloo
so I'm first trying to grasp the discrepancy
Sorry I understand, we're talking a bit past each other
tired ibex
I think thats part of the problem apple might not be sending a country code
and then the parse is pulling area code into country code
random igloo
Apple Pay says (555) 555-5555, in our API we surface phone: '5555555555' but for some reason for you it shows phone: '+5555555555'
I'm trying to figure why you end up with a + in the API when I don't
tired ibex
huh. yeah that is wierd
We are in the out of the box suite of pricing tables and checkout
random igloo
ah let me try pricing table + subscriptions
nope I can't repro that part so I don't get it
But I clearly see the prefix is missing and that's a bug.
I'd recommend writing in to our support team so that they can follow up with you on this though I'm dubious we can this bug quickly
tired ibex
That's my worry
Let's check one other thing
This is a test pricing table on a test sub
Let me ask one of my test users if they can use the other subscription we have built and see if we get a different result
My hope is that this is something borked up in the pricing table/ product config/ checkout relationship
Long shot, but sometimes you have to unplug it and plug it back in first. 🧠
🔌
random igloo
I tried PricingTable locally but don't get that either so it's strange
I flagged the bug internally so if you write in to our support team and mention we spoke then they can help you follow up on this
bitter sirenBOT
tired ibex
Just tested with the other sub we created, no dice. Still the borked parsing on phone coming off the apple pay fullshipping address data
cus_O2yhIExwcsn2pm
copper maple
Hi @tired ibex I'm taking over this thread
tired ibex
Hello Jack Tan with your kitty mermaid, you mermade my day
copper maple
I just went through the chat history. So it's about the phone number prefix isn't set when you checkout with Apple Pay, am I right?
tired ibex
Essentailly. What we are seeing is that when a user pays with apple pay, their phone number arrives with the area code pared into the country code
In the example above you have a LA phone number area code 310 but parsed into the country code, +31
We are using the off the shelf pricing table and subscription config via the dashboard with the provided checkout with the box checked for collect phone
This only happens with apple pay
(that we have seen so far, no issue with Google pay)
random igloo
really this is a bug, next step is to work with support 🙂
copper maple
I see, that's because the +1 is missing. I saw koopajah has already flagged this bug to the relevant team.
tired ibex
copper maple
