stripe-react-native icon indicating copy to clipboard operation
stripe-react-native copied to clipboard

CardForm requires static height — different on iOS/Android and affected by postal code field

Open restarajat opened this issue 4 months ago • 7 comments

When using the CardForm component from @stripe/stripe-react-native, we are forced to provide a fixed height. This creates multiple issues:

  1. Platform inconsistency
  • The required height is different on iOS and Android.
  • Developers need to manually adjust styles per platform, which makes UI maintenance harder.
  1. Postal code field problem
  • Some countries do not require a postal code, but the component still takes up space as if the field is present.
  • Since the height is static, hiding the postal code creates layout issues (extra space or clipped UI).
  1. Lack of dynamic sizing
  • Ideally, the component should be able to size itself dynamically based on which fields are shown.
  • Currently, developers would need to maintain a full list of countries that don’t use postal codes, but this logic should already be handled internally by Stripe.
  1. API limitation
  • The CardForm only exposes onBlur and onFocus events via ref.
  • There’s no way to measure or listen to the internal layout changes in order to adapt the height dynamically.

Steps to reproduce the behaviour:

  1. Install and configure @stripe/stripe-react-native
  2. Add the CardForm component to a screen
  3. Run the app on iOS and note the required height for the form (height: iOS: 200, Android: 300).
  4. Run the same app on Android and observe that the form has a different intrinsic height.
  5. In the CardForm, select a country that does not require a postal code (e.g., [example country you tested: Ireland, Hong Kong, etc.])
  6. Notice that the postal code field disappears — but the height you defined remains static, causing either extra blank space or clipped UI.

Expected behaviour

  • The CardForm should automatically adjust its height depending on platform and visible fields (e.g., postal code).
  • Or, at least expose a method/event to measure its internal content height so developers can size it dynamically.

Smartphone (please complete the following information):

  • Device: iPhone 16 Pro, Pixel 3a
  • OS: iOS18.5, Android 14
  • React Native version: 0.81.0
  • @stripe/stripe-react-native version: 0.51.0

restarajat avatar Aug 23 '25 04:08 restarajat

I’m in the same situation, migrating towards CardForm, and I’m also wondering: Is there any official announcement from the Stripe team about CardForm being deprecated? What’s the current recommended approach for handling card inputs in React Native — should we be moving fully to PaymentSheet / CustomerSheet?

EapRules avatar Aug 26 '25 02:08 EapRules

Hi @restarajat and @EapRules, we are not planning on adding any new features to the CardForm. We are encouraging all users to instead use the Mobile Payment Element, which we launched in 2021. You can find the docs here. If there are any reasons the MPE doesn't support your use case, we'd love to hear your feedback!

joyceqin-stripe avatar Aug 26 '25 18:08 joyceqin-stripe

@joyceqin-stripe Thanks for the update. I just want to clarify my situation to see if I’m missing something.

I’m not using the CardForm for payments directly — I’m only using it for onboarding a user to a client with their card details. From what I understand, the Mobile Payment Element (MPE) is focused on handling payments, but in my flow, I just need to securely collect card details during onboarding.

Right now, I have 3 ways to onboard a user to a client:

Redirect link provided by Stripe

CardForm → collect card details and send through backend onboarding

Bank details

The CardForm is the only embedded option that fits this case, since the redirect flow isn’t always ideal, and bank details are not always provided.

So my question is: is there a way to achieve this onboarding flow with the Mobile Payment Element, or another recommended approach? If MPE can cover this, I’d be happy to switch, but from the docs, it looks like it’s only designed for actual payments.

restarajat avatar Aug 29 '25 07:08 restarajat

Hi @restarajat, if you have an iOS device, check out our in-app elements demo app clip with the Payment Element (also known as Embedded) integration and Setup transaction type— I believe that could be what you're looking for.

You can use the SetupIntent API with the Embedded Payment Element to present payment method options to be set up and saved without attaching a payment to it. This doc is a guide to integrating with Embedded Payment Element and SetupIntents.

Let me know if this was helpful or if you have any more questions!

joyceqin-stripe avatar Aug 29 '25 13:08 joyceqin-stripe

@joyceqin-stripe I am getting This App Clip is not available after opening the link after scanning the QR

restarajat avatar Aug 30 '25 08:08 restarajat

Hi @restarajat— apologies, we haven't done the work to run the app clip on iOS 26 yet. However, let me know if what the docs describe suit your use case!

joyceqin-stripe avatar Sep 04 '25 20:09 joyceqin-stripe

@joyceqin-stripe no, it doesn't

restarajat avatar Sep 06 '25 08:09 restarajat