#.jovanm_
wintry egretBOT
Hello! We'll be with you shortly. Below are links to other discussions we've had with you in the past week in case you want to review that information. If your question is related to one of these previous discussions, please provide a comprehensive summary of the current state and what you need help with now. We help many users simultaneously, so a summary allows us to resolve your issue as soon as possible.
- .jovanm_, 4 days ago, 10 messages
bitter moat
Can you try setting this to never? https://stripe.com/docs/js/elements_object/create_payment_element#payment_element_create-options-fields-billingDetails-address-postalCode
And you will need to pass a value on confirmation instead, if you don't collect it first hand
pulsar bramble
Can you give me an example of the value I need to pass?
bitter moat
never, as the Doc states
pulsar bramble
I mean you said that
And you will need to pass a value on confirmation instead, if you don't collect it first hand
Do I need to pass a value here in confirmPayment?
bitter moat
Scroll up a little bit 🙂
pulsar bramble
I'm not sure how to do this though. Is this the new parameter when I disabled postalCode?
// Confirm the PaymentIntent using the details collected by the Payment Element
const { paymentIntent, error } = await stripe.confirmPayment({
elements,
clientSecret,
payment_method_data: {
billing_details: {
postalCode: 'never'
}
},
confirmParams: {
return_url: window.location.href.split("?")[0] + 'successful-payment',
},
});
A bit different. There are 2 timings:
- When you create the PaymentElement. You can choose to hide the postal code here. The PaymentElement won't display the postal code collection in the UI
- When you confirm the PaymentElement. Here you need to pass a postal code value if you hide it on step 1, because Stripe will need a value eventually
- is
elements.create('payment',options?), 2. isstripe.confirmPayment(options)
pulsar bramble
I already set the postalCode to never but it never hides the postalCode.
So PostalCode is really required since I still need to pass the postal code value?
So, we have this weird scenario where
User-1 is using Card-1 to purchase our monthly subscription.
However,
User-2 is also using Card-1 to purchase our monthly subscription but Card-1 has been declined when he submitted the form.
What's happening here?
Note: User 1 and User 2 inputted different email on our form. In our form, only the payment details is using elements.create();
bitter moat
Is this live mode?
pulsar bramble
This is how I create the payment elements:
const paymentElement = elements.create('payment', {
wallets,
defaultValues: {
billingDetails: {
address: {
country: 'US',
// postalCode: 'never'
}
}
},
});
Yes this is in Live Mode
bitter moat
Aren't you commenting it out?
Can you provice your Test mode page w an accessible URL, when you passed postalCode: 'never'? I can try to look closer
pulsar bramble
Okay sure. But do you know what's happening in our weird scenario?
Our users can't seem to use the same cards when registering different account.
bitter moat
It looks like an error from their issuer bank. If you look at the charge ch_xxx on your Dashboard, what do you see?
pulsar bramble
Is it because of the IP Address?
The User 2 is currently using Card-1 in different country.
Meanwhile, User 1 is using Card-1 in the US when purchasing our subscription.
bitter moat
Yeah could be. That's totally up to the card issuer. Maybe they only allow the card to be used outside the US
I think hiding the postal code here is not the solution. It's the issuer bank restriction and not you as a merchant, to provide a workaround for the customer
The customer need to deal with their issuer bank themselves
pulsar bramble
Is is possible to block postalcode radar rules?
bitter moat
That doesn't look like because of radar rule. Do you have the PaymentIntent Id? pi_xxx
pulsar bramble
Because based on what I've seen here, I can disable the postalcode verification
bitter moat
Let's see how the PI failed. Can you provide the PaymentIntent Id? pi_xx
pulsar bramble
Okay, here's the
PaymentIntent Id
pi_3OF5WVDbxJ8mKm372pkMhmbr
That doesn't look like because of radar rule. Do you have the PaymentIntent Id? pi_xxx
I mean, it is possible to block the postal code verification rule in Stripe?
In order for the future payments to bypass the postal code verification?
bitter moat
Ah yes
This is blocked by that rule
This will also hints you how to disable it
"Disable" button
pulsar bramble
So, here's the payment that went through:
And this is the payment that has been blocked
This is the payment method that failed:
pi_3OF880DbxJ8mKm371zC6TfnN
Can you check why this has failed? I am using my company card, and zip code.
pulsar bramble
I did, is it perhaps we are using the wrong Zip Code?
pulsar bramble
Should I disable it then?
Can you check my code payment elements implementation and see if there's anything wrong with it?
wintry egretBOT
bitter moat
It's the matter of disable your rule or not, not really related to your code
pulsar bramble
Okay my manager seems to be sure that this is related to my code and implementation :/
What will be the repercussions when disabling the postal code verification?
cold orchid
Hi @pulsar bramble I'm taking over this thread
So you want to know what happen if you remove the radar rule for zip code check?
pulsar bramble
Yes
cold orchid
Ok, then Stripe won't block a payment if the zip code check fails.
pulsar bramble
Okay, are we using the wrong postal code based on the payment intent id I provided earlier?
cold orchid
What's the payment intent ID?
pulsar bramble
Here: pi_3OF880DbxJ8mKm371zC6TfnN