You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Stripe always ask, include when disable, for the Postcode detail.
1. By default “Block if Postal code verification fails” came Disabled on stripe
On dashboard, stripe, settings, radar, rules the "Block if Postal code verification fails" came disabled by default.
I asked to Stripe why the “Block if Postal code verification fails” it’s “Disabled” by default, on radar rules, and why they don’t remove/stop asking for postal code on checkout?
Stripe said: it will simply not block any payments if and when the wrong postcode is provided.
I informed the Stripe, because they have "Disabled" the “Block if Postal code verification fails”, we don’t wish ask for the post code details on "Stripe credit card form" and on "Stripe checkout".
2. Stripe credit card form
On checkout of “Stripe credit card form”, after the customer fill the field "Card number", comes up the field "Postcode" and he have to fill.
The Stripe said:
You'll need to remove this from the script, “you can set hidePostalCode=true to remove post code requirements.”
and
“the CardElement accepts all the options as defined in Stripe.js reference, so you can set hidePostalCode=true to remove the zip code field from showing”.
3. Stripe checkout
On checkout keep asking for "Postal code" on “Stripe checkout integration”.
“
disabling the rules will only instruct the system to still complete the payment even if the wrong post code is being entered by the customer as mentioned, you can set hidePostalCode=true to remove the zip code field from showing
“
if you're using our custom built Stripe Checkout page - the post code field is already built in
if you want to change this using our Checkout page, you'll need to do this on your end by setting "hidePostalCode=true" in the CardElement parameter
”
5. Problem
With this problem given by Stripe, we have two majors’ problems:
A customer not submitting their card information, because Stripe ask for Postcode/Postal code (postal code validation the Stripe don’t do) and we don't sell,
After, the customer can cancel the order and Stripe still charge us.
6. Solution on Stripe checkout integration
The Stripe solution:
When the “Block if Postal code verification fails” it’s “Disabled” by default or by option, on radar rules, the Stripe could remove/stop asking for postal code on Stripe checkout integration.
Or
When the “Block if Postal code verification fails” isn’t “Disabled”, on radar rules, the stripe after the costumer fill the Card information they could check if it’s necessary ask the Postcode and if necessary open the field Postal code.
7. Solution on Stripe credit card form
We think its good option if on Back Office on “CREDIT CARD FORM DESIGN” we could check if we want “Zip code / Postcode / Postal code verification” or not.
Picture of TB post "Stripe - Postcode thirtybees/thirtybees#941", now the version Stripe 1.7.1 don’t have “Enforce 3D Secure”.
With this new button we can match the Stripe credit card form
with configuration “Postal code verification fails” on radar rules on Stripe.
The text was updated successfully, but these errors were encountered:
The Stripe always ask, include when disable, for the Postcode detail.
1. By default “Block if Postal code verification fails” came Disabled on stripe
On dashboard, stripe, settings, radar, rules the "Block if Postal code verification fails" came disabled by default.
I asked to Stripe why the “Block if Postal code verification fails” it’s “Disabled” by default, on radar rules, and why they don’t remove/stop asking for postal code on checkout?
Stripe said: it will simply not block any payments if and when the wrong postcode is provided.
I informed the Stripe, because they have "Disabled" the “Block if Postal code verification fails”, we don’t wish ask for the post code details on "Stripe credit card form" and on "Stripe checkout".
2. Stripe credit card form
On checkout of “Stripe credit card form”, after the customer fill the field "Card number", comes up the field "Postcode" and he have to fill.
The Stripe said:
and
3. Stripe checkout
On checkout keep asking for "Postal code" on “Stripe checkout integration”.
The Stripe said, if you're using the Stripe Checkout option, you'll need to set "hidePostalCode=true" when collection the card details to remove this field.
https://stripe.com/docs/payments/accept-a-payment?integration=elements#web-collect-card-details
4. Resume of Stripe
“
disabling the rules will only instruct the system to still complete the payment even if the wrong post code is being entered by the customer as mentioned, you can set hidePostalCode=true to remove the zip code field from showing
you may use this link here for reference
https://stripe.com/docs/js
https://stripe.com/docs/payments/accept-a-payment?integration=elements#web-collect-card-details
removing the post code field required API coding to be done
you can also refer to these links here for details
https://stackoverflow.com/questions/46863072/do-not-collect-zip-code-with-stripe
stripe-archive/react-stripe-elements#20
”
“
if you're using our custom built Stripe Checkout page - the post code field is already built in
if you want to change this using our Checkout page, you'll need to do this on your end by setting "hidePostalCode=true" in the CardElement parameter
”
5. Problem
With this problem given by Stripe, we have two majors’ problems:
6. Solution on Stripe checkout integration
The Stripe solution:
Or
7. Solution on Stripe credit card form
We think its good option if on Back Office on “CREDIT CARD FORM DESIGN” we could check if we want “Zip code / Postcode / Postal code verification” or not.
Picture of TB post "Stripe - Postcode thirtybees/thirtybees#941", now the version Stripe 1.7.1 don’t have “Enforce 3D Secure”.
With this new button we can match the Stripe credit card form
with configuration “Postal code verification fails” on radar rules on Stripe.
The text was updated successfully, but these errors were encountered: