#sroyqci=charges

1 messages · Page 1 of 1 (latest)

tiny orbit
#

Hello! Starting up a thread for you

rose solar
#

Hello! I'm fairly new to Discord, so I hope I did things correctly there!

#

My initial message was too long apparently, so I had to split it up into 2 messages. Here's the remainder since I don't see that here in this thread:

#

Is what I'm outlining above expected?

If so, what would be the guidance/best-practice to follow? Should we just always axe off the plus-four from the zip code and never send it in the ChargeService.Create() call? Should we continue sending the full zip plus-four value, and if that fails, try the call again with a truncated/non-plus-four zip code? Does Stripe have any logic (or plans to add logic) to accomplish this truncate-and-retry approach on your end for this zip code plus-four scenario?

Thanks in advance for any help!

tiny orbit
#

I don't know a ton about what specifically is best practice here, but I know that our own card element UI only accepts a 5 digit zip code for the US. If you heavily rely on the AVS checks passing then I'd recommend just changing your code to do the truncation and pass the basic zip code moving forward.

rose solar
#

Ok thanks! Great point about the card element UI only accepting 5 digits anyway.

#

I did have a call with Stripe support prior to hopping on here (they're the ones who suggested coming here, as I didn't know there was a Stripe dev Discord 😀 ), but their only other suggestion was turning off the zip code validation rule in Radar. I don't think my client would want to do that, though

#

So I will look more into this Adaptive Acceptance and possibly reach back out to support on that

tiny orbit
#

Yeah definitely look into adaptive acceptance, and moving to the 5 digit zip (just to match what stripe is doing)

rose solar
#

Yep, you bet. Great ideas/suggestions! I really appreciate it!!