svg-credit-card-payment-icons: 80 payment logos in six SVG styles

A set of marks, not a component, and that shapes everything else

The repository describes itself as a collection of SVG based credit card logo and payment icons, and the description line says it plainly: 6 Styles, 80 Icons. So the deliverable is files, not a library.

That is a narrower thing than most payment icon sets, and worth being clear about before reading on. There is no dropdown component, no React wrapper, no theme object and no way to ask the code which brands are supported at runtime. What there is, per brand, six drawings in six directories at the top of the tree: flat, flat-rounded, logo, logo-border, mono and mono-outline.

The two ends of that list are the interesting contrast. The flat set is a solid silhouette, which is what you want at 16 pixels next to an input field. The mono and mono-outline sets are single-colour monochrome forms, which is what you want in a footer, a receipt or a settings screen where you want the brand to be present without competing with the content. The logo and logo-border sets are the full-colour brand marks with a surrounding rounded border, which is the version you use when the mark itself is the thing.

Six styles for one brand is the part that is not ordinary. Most collections give you a logo and maybe a monochrome variant, and leave you to guess what a 20-pixel flat mark should look like. Here the flat and flat-rounded pair differs only in corner treatment, and the mono and mono-outline pair differs only in whether the shape is filled or stroked, so you have a designed answer for both a filled slot and an outlined one.

Every file is addressed by brand name and style directory

The mechanism is a plain directory convention, and it is worth knowing precisely because it determines how you reference the assets.

Each icon is a file named after the brand, inside the directory for its style. The Alipay mark is flat/alipay.svg, flat-rounded/alipay.svg, logo/alipay.svg, logo-border/alipay.svg, mono/alipay.svg and mono-outline/alipay.svg. The same pattern holds for American Express as amex.svg, for Diners as diners.svg, for Discover as discover.svg, for Elo as elo.svg, for Hiper as hiper.svg, for Hipercard as hipercard.svg, and for JCB as jcb.svg.

Two consequences follow. First, the file name is the brand key, so a checkout that stores a payment method code can map that code to a path with a lookup rather than a hard-coded asset table. Second, because the naming is consistent, you can generate the path at runtime from the style you chose and the brand you have, which is what makes a six-style set practical to adopt rather than merely pleasant to look at.

There is also a machine-readable index at the top of the tree, credit-card-payment-icons.json, which is the file to read if you want the brand list without parsing the README table. The README table itself renders every brand against every style, which is the fastest way to see the range: the flat column reads as solid silhouettes, the logo column as full-colour marks, and the mono columns as the outline and filled monochrome pair.

The npm package exists, and the usage documentation does not

The repository announces that the collection is now available as a Node/NPM package, linked to the GitHub Packages registry path for ccicons. The package metadata in the tree names it @aaronfagan/ccicons at version 0.1.1, with the entry point at src/index.js.

The usage section of the project documentation is a single line: Coming soon!

That is the honest state of the project and it is worth stating plainly rather than papering over. The package is published and the assets are there, but there is no documented import, no documented component shape, no documented list of exported names. If you take the package, you are reading src/index.js to find out what it exports, which is a reasonable thing to do for an asset package and a poor experience for a library.

The build tooling in the tree is more informative than the missing docs, because it tells you the package is assembled by webpack rather than shipped as raw files. There are four webpack configs, webpack.common.js, webpack.demo.js, webpack.prod.js and webpack.test.js, and the package scripts wire them up:

  "scripts": {
    "build:demo": "webpack --config=webpack.demo.js",
    "build:test": "webpack --config=webpack.test.js",
    "build:develop": "npm run build:demo && npm run build:test",
    "build:release": "webpack --config=webpack.prod.js",
    "build": "npm run build:release",
    "start": "webpack serve --open --config webpack.demo.js",
    "test": "webpack serve --open --config webpack.test.js"
  },

So the demo and the test page are separate webpack bundles, the release bundle is the one the package is built from, and the start and test scripts both open a dev server in the browser. The test framework in the dev dependencies is mocha with chai, and there is a test/ directory and a src/ directory alongside the asset directories, which is where the bundle entry points and the icon data live.

Getting the files, and the two ways you can take them

There is no install script to copy from the documentation, so the realistic options are the ones the project documentation supports.

The first is to take the SVG files directly from the repository, either by cloning it or by pulling the individual files from the raw path the table in the project documentation uses for each icon preview. The table's image links point at a raw URL of the form https://github.com/aaronfagan/svg-credit-card-payment-icons/raw/main/flat/alipay.svg, so the addressing scheme is public and stable enough to script against.

The second is the npm package, installed as @aaronfagan/ccicons, with the note that its published entry point is src/index.js.

A third path exists in the tree for people working on the collection itself rather than consuming it: DEVELOP.md sits at the top level next to the README, and the webpack scripts above are the development loop. The dev server opens a demo page and a test page, which is how you would check a redrawn icon in a browser before committing it.

What is not documented anywhere in the project documentation is how the package exposes the assets once installed, whether it inlines SVG markup, emits URLs, or returns imported components. Since the Usage section is marked as coming soon, that question has to be answered by reading src/index.js, and a team planning a checkout integration should budget that time rather than assume the obvious.

Where this collection is the wrong choice

The first limit is that a payment method picker is a piece of product, and this is a piece of artwork. Icons alone do not tell a user which cards you accept, whether you take a prepaid card, or what happens if a card is declined. If you need that, you build the selector and you borrow the marks from here, and the gap between the two is where your real work sits.

The second limit is currency of the marks themselves. The repository carries no stated process for keeping a brand set current, and a card network that rebrands or a provider that changes its logo leaves the file in this repository out of date until somebody redraws it. The repository's own release history is two tags: v0.1.0 on 2024-07-29 and v0.1.1 on 2024-08-06. The last push to the repository was on 2026-04-28, so the files have moved since the last release, which means the npm package and the repository contents are not the same thing.

The third is that a set of marks is not a set of logos. These are redrawn silhouettes and simplified marks rather than the official brand assets, which is precisely why they can be distributed under an open source licence at all, and also precisely why a brand team will not accept them in place of their own artwork. If a partner or a payment provider asks for the official logo, the answer is to ask them, not to reach for this repository.

The fourth is the workflow gap the same fact implies. A team with a design system wants the marks to inherit the system's sizing, colour and spacing rules, and a per-brand set of SVGs with six hand-tuned variants per brand does not automatically do that. You end up maintaining an override layer of your own.

Compared with a general purpose icon set

The alternative is a general purpose icon library, and the difference in approach is the point.

A general icon set gives you one house style across everything: your interface, your product, your marketing site, all the same weight and geometry, with a build step that produces a font or a sprite and a documented size and colour system. That consistency is exactly what you want for an interface, and exactly what you do not need for a row of third-party brand marks.

Brand marks are the exception to that rule. A Visa mark next to a Mastercard mark next to an American Express mark has to look like the three separate things it represents, and a general icon set cannot deliver that, because a house style flattens exactly the differences you need preserved. This collection takes the opposite position: each brand is drawn to be recognisable and the collection is internally consistent within a style, not across styles.

The second difference is coverage. General icon sets cover interface symbols. This one covers the payment brands a checkout actually needs, and it covers them in the monochrome variants an interface needs and the flat variants a dense form needs, which a general set has no reason to produce.

The trade is the mirror image of the first one. Choosing this set means giving up the design system integration you get from a general library, and you are left maintaining your own layer that applies your sizing and colour rules to six variants per brand. For a checkout page that is a reasonable trade. For an application iconography as a whole it is not.

Editorial conclusion

svg-credit-card-payment-icons is worth taking the files from if you are building a checkout, a payment method picker or a billing screen and you want brand marks that match each other, because six styles per brand is unusual and because the SVG source means the marks scale without a second set of raster files. It is the wrong tool if you need a component with behaviour, since there is none, and the wrong tool if you need to know that a brand mark is current, because the repository carries no process for that. Before you ship the assets, check the three things the repository itself leaves to you: that the usage section is still marked as coming soon, so the npm entry point and its exports are not documented and you will be reading src/index.js to find out what you get; that the published npm version is 0.1.1 from 2024-08-06 while the last push to the repository was on 2026-04-28, so the package may lag the files; and the licence, which is Apache-2.0 with a LICENSE file in the tree, and which your organisation should read rather than assume, since payment logos are also trademarked marks and the copyright status of the drawings is a separate question from the licence of the collection.

Frequently asked questions

Official sources

1. aaronfagan/svg-credit-card-payment-icons on GitHub
2. License: Apache-2.0
3. Project website
4. README
5. Releases