# flutter_credit_card draws a card face and a card form for Flutter apps

> The flutter_credit_card package from Simform gives Flutter apps a credit card widget with brand detection, glassmorphism, a floating card animation and a matching form widget with validation hooks. It suits checkout screens that want a card preview, and version 4 removed the colour properties many earlier tutorials still use.

**SimformSolutionsPvtLtd/flutter_credit_card** — A credit card widget for Flutter application.

- Repository: https://github.com/SimformSolutionsPvtLtd/flutter_credit_card
- Website: https://pub.dev/packages/flutter_credit_card
- Stars: 598 · Forks: 309
- Language: Dart
- License: MIT
- Published: 2026-10-22 · Updated: 2026-10-22 · Language: en
- Canonical page: https://hysenlabs.com/projects/simformsolutionspvtltd-flutter-credit-card

## Two widgets, one card face

flutter_credit_card is a Flutter package from SimformSolutionsPvtLtd for implementing a credit card interface with card detection, published on pub.dev and licensed under MIT. What arrives is two related widgets rather than one. CreditCardWidget is the display element, the physical card face with a chip, a number, an expiry, a holder name and a network logo, and it is where brand detection lives. CreditCardForm is the input element, a set of fields for the same four values with a validation layer attached. They are designed to be used together, since the form's model change callback is what tells the card widget what to show, but they are separable and the documentation presents them as separate steps, adding the widget first and the form afterwards. That separation is the useful architectural detail. A checkout screen can show a static card face with no input at all, for example on an order confirmation page showing what was charged, and a payment sheet can use the form without ever rendering a card. The package is pure Flutter with no platform channels in the repository layout, which is why the same widget renders on Android, iOS, web, macOS, Linux and Windows, and the example app carries directories for each of those platforms.

## Brand detection and the back view for the CVV

The mechanism that makes the widget more than a picture is card detection, and the required parameters show how little you have to supply to get it. The widget takes the card number, expiry date, card holder name and CVV code, plus a showBackView flag that is true when you want to show the cvv back view, and a callback that fires any time the credit card brand is changed.

```dart
    CreditCardWidget(
      cardNumber: cardNumber,
      expiryDate: expiryDate,
      cardHolderName: cardHolderName,
      cvvCode: cvvCode,
      showBackView: isCvvFocused, //true when you want to show cvv(back) view
      onCreditCardWidgetChange: (CreditCardBrand brand) {}, // Callback for anytime credit card brand is changed
    ),
```

Two details in that snippet carry most of the behaviour. The showBackView flag is normally wired to the focus state of your CVV field, so the card physically flips to show the security code when the user reaches that input and flips back when they leave it, which is a small piece of interaction polish that would otherwise take a rotation animation and a second widget. The onCreditCardWidgetChange callback fires whenever the detected brand changes, so you can show the right network logo, or adjust the accent colour, without re-deriving the brand yourself from the number's prefix. The brand is also settable directly, through the cardType property, so an app that already knows the card type does not have to wait for the user to finish typing.

## The optional parameters are where the design lives

The optional parameters list in the documentation is long, and reading it is the fastest way to understand what the package considers its feature set. There is backgroundImage for a local asset and backgroundNetworkImage for a remote URL, a bankName string, and cardBgColor for the flat case. Labels are configurable through labelCardHolder and labelValidThru, so the text on the face of the card is not fixed English. Obscuring is handled by three flags, obscureCardNumber, obscureInitialCardNumber and obscureCardCvv, which lets you show the first few digits of a stored number while masking the rest, or mask everything. Layout is covered by height, width, padding, and the frontCardBorder and backCardBorder decorations, with chipColor and isChipVisible for the chip element. The card type can be forced with cardType, and customCardTypeIcons takes a list of CustomCardTypeIcons entries where each entry pairs a card type with an Image, so an app with its own network artwork can supply it. isSwipeGestureEnabled and animationDuration control the flip interaction, and textStyle sets the typography. The design of the API is consistent throughout, which is the mark of a package that has had a few major versions of feedback applied to it.

## Glassmorphism: blur, gradient and a flat default

The glassmorphism look is a separate configuration object rather than a set of loose booleans, and the default is a one-liner.

```dart
    CreditCardWidget(
      glassmorphismConfig: Glassmorphism.defaultConfig(),
    );
```

The custom form takes a blur radius on each axis, a gradient with a begin and end alignment, a list of colours and a list of stops, so the frost is defined as a shape rather than as a pile of transparency values.

```dart
    CreditCardWidget(
      glassmorphismConfig: Glassmorphism(
        blurX: 10.0,
        blurY: 10.0,
        gradient: LinearGradient(
          begin: Alignment.topLeft,
          end: Alignment.bottomRight,
          colors: <Color>[
            Colors.grey.withAlpha(20),
            Colors.white.withAlpha(20),
          ],
          stops: const <double>[
            0.3,
            0,
          ],
        ),
      ),
    ),
```

The stops list in that example is worth noting, because a stop of 0 sits after a stop of 0.3, which is unusual ordering for a gradient and produces the hard transition some glass treatments rely on. It is a reminder that the configuration is a raw LinearGradient and not a curated abstraction, so you get Flutter's semantics exactly, including the freedom to get them wrong.

## The floating card and its web caveat

The floating card is the effect where the card lifts off the surface on a pointer, tilts, and catches a glare. It is enabled with a flag and configured through a FloatingConfig.

```dart
    CreditCardWidget(
        enableFloatingCard: true,
        floatingConfig: FloatingConfig(
            isGlareEnabled: true,
            isShadowEnabled: true,
            shadowConfig: FloatingShadowConfig(
              offset: Offset(10, 10),
              color: Colors.black84,
              blurRadius: 15,
            ),
        ),
    );
```

The shadow itself has its own configuration object, with an offset, a colour and a blur radius, so the depth of the lift is not hard-coded. The important limitation is stated in the documentation as a note directly after the example: currently the floating card animation is not supported on mobile platform browsers. That is a platform gap, not a platform independence claim, and it matters because the same effect works on desktop web, as the repository's preview assets show a floating card on web with a cursor, and does not work in a mobile browser. The package topics list both android and ios alongside the Flutter and web targets, so the omission is specific to the animation in mobile browsers rather than to the package as a whole.

## The form widget and where validation actually happens

CreditCardForm is where the package stops being presentational. The form takes a form key and the four card values, four field keys for the card number, CVV, expiry date and holder name, and a required model change callback, plus visibility flags for the CVV, the number, the holder name and the expiry date, and an enableCvv switch.

```dart
    CreditCardForm(
      formKey: formKey, // Required 
      cardNumber: cardNumber, // Required
      expiryDate: expiryDate, // Required
      cardHolderName: cardHolderName, // Required
      cvvCode: cvvCode, // Required
      cardNumberKey: cardNumberKey,
      cvvCodeKey: cvvCodeKey,
      expiryDateKey: expiryDateKey,
      cardHolderKey: cardHolderKey,
      onCreditCardModelChange: (CreditCardModel data) {}, // Required
      obscureCvv: true, 
      obscureNumber: true,
```

The validation story is the part to design around. The form ships its own messages, cvvValidationMessage, dateValidationMessage and numberValidationMessage, with English defaults you would replace, and it also accepts cardNumberValidator, expiryDateValidator and cvvValidator callbacks that take a string and return something the form's validator machinery understands. So there are two levels: a built in check for a well formed number, date or code, and a hook for whatever else your business rules require, such as a card type you do not accept. Note that the fields are not obscured by default in the sense of hiding input, the obscureCvv and obscureNumber flags control that, and that onCreditCardModelChange is the bridge back to the card widget.

## The 4.x migration, where the properties went

The migration guide for version 4.x.x is the section to read before you look at any tutorial, and it describes two removals that will break older code outright. The themeColor, textColor and cursorColor properties have been removed from CreditCardForm due to changes in how it detects and applies application themes, and the documentation points you at the example app to learn how to apply those using Theme. That is a deliberate design decision rather than a gap. The widget now follows the ambient application theme instead of carrying its own colours, so a card form inside a dark mode app looks right without per-instance configuration, and the cursor colour follows the text field theme the platform already resolved. The second change is where the per-field decoration properties went. The cardNumberDecoration, expiryDateDecoration, cvvCodeDecoration and cardHolderDecoration properties are moved to the newly added InputDecoration class, which also has textStyle properties for all the textFields of the CreditCardForm. So the styling hooks did not disappear, they moved into a wrapper object, and the wrapper also carries the text style for the fields. If you are porting from a 3.x tutorial, that is the whole diff.

## Where the package sits in release terms

The release history shows a project at 4.1.0, published on 2025-02-25, with 4.0.1 on 2025-01-10 and 4.0.0+1 on 2023-10-05 before it. The version numbers tell the story of the migration described above, since 4.0 is where the theme and decoration properties moved, and the 4.0.0+1 suffix is a build publication of the same feature version. The last push to the repository was on 2026-06-10, and the repository is not archived, so the tree is still being worked on even though the last tagged release is over a year behind that push. The repository contents match a Flutter package convention, with lib/ for the source, example/ carrying a full multi platform app, test/ and an analysis_options.yaml for lint configuration, plus android/ and ios/ directories, a font/ directory for the type on the card face, icons/ for the network logos, and readme_assets/ for the preview images. The licence is MIT, so the code can be used in commercial applications with attribution, and the assets inside the package, in particular the network logos, carry their own trademark situation that a legal team may want to look at separately.

## Conclusion

Adopt flutter_credit_card if your Flutter checkout flow needs a card face that reacts to input, supports the usual card networks through brand detection, and looks the same on mobile and web, and if you are starting fresh on version 4.x. Do not adopt it if you need a card that talks to a payment processor, since the widget is presentation only, or if you are copying a pre-4.x tutorial, because the themeColor, textColor and cursorColor properties were removed along with the per-field decoration properties that moved into the new InputDecoration class. Verify two things before you commit: that the 4.x migration guide matches your code, since the example app is the documented way to learn how the replacement Theme and InputDecoration work, and that the floating card animation is acceptable on your target, because the README states it is not supported on mobile platform browsers. The practical first step is to add the dependency to pubspec.yaml, import the package, and run the required-parameter CreditCardWidget in a scratch screen before you style anything.

## FAQ

### What does the flutter_credit_card package provide?

It provides a Flutter package for implementing a credit card interface with card detection, delivered as two widgets: CreditCardWidget for the card face and CreditCardForm for the input fields with validation hooks.

### How do I add flutter_credit_card to a Flutter project?

Add the dependency to pubspec.yaml using the latest version from the Installing tab on pub.dev, then import it with import 'package:flutter_credit_card/flutter_credit_card.dart'; and add the CreditCardWidget to your widget tree.

### What changed in version 4.x of flutter_credit_card?

The themeColor, textColor and cursorColor properties were removed from CreditCardForm because of changes in how it detects and applies application themes, and the cardNumberDecoration, expiryDateDecoration, cvvCodeDecoration and cardHolderDecoration properties moved to the newly added InputDecoration class, which also has textStyle properties for the text fields.

### Does flutter_credit_card support the floating card on mobile browsers?

No. The documentation states that the floating card animation is not supported on mobile platform browsers, while the same effect is available in the web build shown in the repository's preview assets.

### How does flutter_credit_card detect the card brand?

The widget detects the brand from the card number and reports it through the onCreditCardWidgetChange callback, which fires any time the credit card brand is changed. You can also set the brand directly with the cardType property, and supply your own network artwork through customCardTypeIcons.

## Sources

- [License: MIT](https://github.com/SimformSolutionsPvtLtd/flutter_credit_card/blob/master/LICENSE)
- [Project website](https://pub.dev/packages/flutter_credit_card)
- [README](https://github.com/SimformSolutionsPvtLtd/flutter_credit_card/blob/master/README.md)
- [Releases](https://github.com/SimformSolutionsPvtLtd/flutter_credit_card/releases)
- [SimformSolutionsPvtLtd/flutter_credit_card on GitHub](https://github.com/SimformSolutionsPvtLtd/flutter_credit_card)

---

Hysen Labs editorial analysis, written from the project's own repository and release notes. Cite the canonical page: https://hysenlabs.com/projects/simformsolutionspvtltd-flutter-credit-card
