HackerReposA FIELD GUIDE TO OPEN SOURCE
ProSponsor the shelf♧ 0
← Back to top all-time
stripe-archive
jquery.payment
CoffeeScript2013–2015
stripe-archive / jquery.payment · Archived

jquery.payment

[DEPRECATED] A general purpose library for building credit card forms, validating inputs and formatting numbers.

15Distinct people
17Mentions
0Explicit recommenders
3.5KGitHub stars
REPOSITORY AT A GLANCE

What to know before exploring

What it is

[DEPRECATED] A general purpose library for building credit card forms, validating inputs and formatting numbers.

GitHub

Where it is used

No documented product use was verified in the last source check.

What people are saying

No recommendation phrase was found in the indexed comments.

No classified warning is attached to this page. Read the discussions before treating silence as approval.

Also in these discussions

No other repository is repeatedly linked in the same discussions.

This week on Hacker News

Nov 7–Nov 14 UTC · Direct repository links and separately labeled related project stories. Indexed through 11/14/2026, 3:56:07 PM UTC.

No direct repository links were found in the indexed HN discussions over the past seven days. Older discussions are available below.

Mentions over time

HN mentions by month17 dated mentions

Observed mentions: 2013-02-07 19:48:44 UTC to 2015-09-03 19:02:49 UTC.

012342013-02-01 00:00:00 UTC to 2013-03-01 00:00:00 UTC (exclusive): 4 mentions; 1 submissions, 3 commentsFeb 20132013-03-01 00:00:00 UTC to 2013-04-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2013-04-01 00:00:00 UTC to 2013-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-05-01 00:00:00 UTC to 2013-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-06-01 00:00:00 UTC to 2013-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-07-01 00:00:00 UTC to 2013-08-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-08-01 00:00:00 UTC to 2013-09-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2013-09-01 00:00:00 UTC to 2013-10-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2013-10-01 00:00:00 UTC to 2013-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2013-11-01 00:00:00 UTC to 2013-12-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2013-12-01 00:00:00 UTC to 2014-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-01-01 00:00:00 UTC to 2014-02-01 00:00:00 UTC (exclusive): 2 mentions; 0 submissions, 2 comments2014-02-01 00:00:00 UTC to 2014-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-03-01 00:00:00 UTC to 2014-04-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-04-01 00:00:00 UTC to 2014-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-05-01 00:00:00 UTC to 2014-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 commentsMay 20142014-06-01 00:00:00 UTC to 2014-07-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2014-07-01 00:00:00 UTC to 2014-08-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2014-08-01 00:00:00 UTC to 2014-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-09-01 00:00:00 UTC to 2014-10-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-10-01 00:00:00 UTC to 2014-11-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-11-01 00:00:00 UTC to 2014-12-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2014-12-01 00:00:00 UTC to 2015-01-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-01-01 00:00:00 UTC to 2015-02-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-02-01 00:00:00 UTC to 2015-03-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-03-01 00:00:00 UTC to 2015-04-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-04-01 00:00:00 UTC to 2015-05-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-05-01 00:00:00 UTC to 2015-06-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-06-01 00:00:00 UTC to 2015-07-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-07-01 00:00:00 UTC to 2015-08-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 comments2015-08-01 00:00:00 UTC to 2015-09-01 00:00:00 UTC (exclusive): 0 mentions; 0 submissions, 0 comments2015-09-01 00:00:00 UTC to 2015-10-01 00:00:00 UTC (exclusive): 1 mentions; 0 submissions, 1 commentsSep 2015

Counts come from the repository’s dated source evidence. Index cutoff: 2026-11-02 08:16:59 UTC.

View mention counts and date ranges
UTC ranges include their start and exclude their end. Select a period to filter the source evidence.
PeriodStart (UTC)End (exclusive, UTC)MentionsSubmissionsComments
Feb 20132013-02-01 00:00:00 UTC2013-03-01 00:00:00 UTC413
Mar 20132013-03-01 00:00:00 UTC2013-04-01 00:00:00 UTC202
Apr 20132013-04-01 00:00:00 UTC2013-05-01 00:00:00 UTC000
May 20132013-05-01 00:00:00 UTC2013-06-01 00:00:00 UTC000
Jun 20132013-06-01 00:00:00 UTC2013-07-01 00:00:00 UTC000
Jul 20132013-07-01 00:00:00 UTC2013-08-01 00:00:00 UTC000
Aug 20132013-08-01 00:00:00 UTC2013-09-01 00:00:00 UTC101
Sep 20132013-09-01 00:00:00 UTC2013-10-01 00:00:00 UTC202
Oct 20132013-10-01 00:00:00 UTC2013-11-01 00:00:00 UTC000
Nov 20132013-11-01 00:00:00 UTC2013-12-01 00:00:00 UTC101
Dec 20132013-12-01 00:00:00 UTC2014-01-01 00:00:00 UTC000
Jan 20142014-01-01 00:00:00 UTC2014-02-01 00:00:00 UTC202
Feb 20142014-02-01 00:00:00 UTC2014-03-01 00:00:00 UTC000
Mar 20142014-03-01 00:00:00 UTC2014-04-01 00:00:00 UTC000
Apr 20142014-04-01 00:00:00 UTC2014-05-01 00:00:00 UTC000
May 20142014-05-01 00:00:00 UTC2014-06-01 00:00:00 UTC000
Jun 20142014-06-01 00:00:00 UTC2014-07-01 00:00:00 UTC101
Jul 20142014-07-01 00:00:00 UTC2014-08-01 00:00:00 UTC101
Aug 20142014-08-01 00:00:00 UTC2014-09-01 00:00:00 UTC000
Sep 20142014-09-01 00:00:00 UTC2014-10-01 00:00:00 UTC000
Oct 20142014-10-01 00:00:00 UTC2014-11-01 00:00:00 UTC000
Nov 20142014-11-01 00:00:00 UTC2014-12-01 00:00:00 UTC000
Dec 20142014-12-01 00:00:00 UTC2015-01-01 00:00:00 UTC000
Jan 20152015-01-01 00:00:00 UTC2015-02-01 00:00:00 UTC000
Feb 20152015-02-01 00:00:00 UTC2015-03-01 00:00:00 UTC000
Mar 20152015-03-01 00:00:00 UTC2015-04-01 00:00:00 UTC101
Apr 20152015-04-01 00:00:00 UTC2015-05-01 00:00:00 UTC000
May 20152015-05-01 00:00:00 UTC2015-06-01 00:00:00 UTC000
Jun 20152015-06-01 00:00:00 UTC2015-07-01 00:00:00 UTC000
Jul 20152015-07-01 00:00:00 UTC2015-08-01 00:00:00 UTC101
Aug 20152015-08-01 00:00:00 UTC2015-09-01 00:00:00 UTC000
Sep 20152015-09-01 00:00:00 UTC2015-10-01 00:00:00 UTC101

From the project README

An excerpt from the repository, fetched Nov 13, 2026.

Read the project’s introduction
jQuery.payment A general purpose library for building credit card forms, validating inputs and formatting numbers. Project status jquery.payment is deprecated. We recommend that you use either Stripe Checkout or Stripe Elements to collect card information. We will patch jquery.payment for major critical/security issues, but we won't be adding new features. Usage You can make an input act like a credit card field (with number formatting and length restriction): $('input.cc-num').payment('formatCardNumber'); Then, when the payment form is submitted, you can validate the card number on the client-side: var valid = $.payment.validateCardNumber($('input.cc-num').val()); if (!valid) { alert('Your card is not valid!'); return false; } You can find a full demo here. Supported card types are: Visa MasterCard American Express Diners Club Discover UnionPay JCB Maestro Forbrugsforeningen Dankort (Additional card types are supported by extending the $.payment.cards array.) API $.fn.payment('formatCardNumber') Formats card numbers: Includes a space between every 4 digits Restricts input to numbers Limits to 16 numbers Supports American Express formatting Adds a class of the card type (e.g. 'visa') to the input Example: $('input.cc-num').payment('formatCardNumber'); $.fn.payment('formatCardExpiry') Formats card expiry: Includes a / between the month and year Restricts input to numbers Restricts length Example: $('input.cc-exp').payment('formatCardExpiry'); $.fn.payment('formatCardCVC') Formats card CVC: Restricts length to 4 numbers Restricts input to numbers Example: $('input.cc-cvc').payment('formatCardCVC'); $.fn.payment('restrictNumeric') General numeric input restriction. Example: $('[data-numeric]').payment('restrictNumeric'); $.payment.validateCardNumber(number) Validates a card number: Validates numbers Validates Luhn algorithm Validates length Example: $.payment.validateCardNumber('4242 4242 4242 4242'); //=> true $.payment.validateCardExpiry(month, year) Validates a card expiry: Validates numbers Validates in the future Supports year shorthand Example: $.payment.validateCardExpiry('05', '20'); //=> true $.payment.validateCardExpiry('05', '2015'); //=> true $.payment.validateCardExpiry('05', '05'); //=> false $.payment.validateCardCVC(cvc, type) Validates a card CVC: Validates number Validates length to 4 Example: $.payment.validateCardCVC('123'); //=> true $.payment.validateCardCVC('123', 'amex'); //=> true $.payment.validateCardCVC('1234', 'amex'); //=> true $.payment.validateCardCVC('12344'); //=> false $.payment.cardType(number) Returns a card type. Either: visa mastercard amex dinersclub discover unionpay jcb maestro forbrugsforeningen dankort The function will return null if the card type can't be determined. Example: $.payment.cardType('4242 4242 4242 4242'); //=> 'visa' $.payment.cardExpiryVal(string) and $.fn.payment('cardExpiryVal') Parses a credit card expiry in the form of MM/YYYY, returning an object containing the month and year. Shorthand years, such as 13 are also supported (and converted into the longhand, e.g. 2013). $.payment.cardExpiryVal('03 / 2025'); //=> {month: 3, year: 2025} $.payment.cardExpiryVal('05 / 04'); //=> {month: 5, year: 2004} $('input.cc-exp').payment('cardExpiryVal') //=> {month: 4, year: 2020} This function doesn't perform any validation of the month or year; use $.payment.validateCardExpiry(month, year) for that. $.payment.cards Array of objects that describe valid card types. Each object should contain the following fields: { // Card type, as returned by $.payment.cardType. type: 'mastercard', // Array of prefixes used to identify the card type. patterns: [ 51, 52, 53, 54, 55, 22, 23, 24, 25, 26, 27 ], // Array of valid card number lengths. length: [16], // Array of valid card CVC lengths. cvcLength: [3], // Boolean indicating whether a valid card number should satisfy the Luhn check. luhn: true, // Regex used to format the card number. Each match is joined with a space. format: /(\d{1,4})/g } When identifying a card type, the array is traversed in order until the card number matches a prefix in patterns. For this reason, patterns with higher specificity should appear towards the beginning of the array. Example Look in ./example/index.html Building Run cake build Running tests Run cake test Autocomplete recommendations We recommend you turn autocomplete on for credit card forms, except for the CVC field (which should never be stored). You can do this by setting the autocomplete attribute: <form autocomplete="on"> <input class="cc-number" autocomplete="cc-number"> <input class="cc-exp" autocomplete="cc-exp"> <input class="cc-cvc" autocomplete="off"> </form> You should mark up your fields using the Autofill spec. These are respected by a number of browsers, including Chrome, Safari, Firefox. Mobile recommendations We recommend you to use <input type="tel"> which will cause the numeric keyboard to be displayed on mobile devices: <input type="tel" class="cc-number">
Read the full README on GitHub

What Hacker News says

17 sources
jquery.payment from stripe[0] helps with formatting and automatically adjusts it to the card type as you type in the numbers. It does seem to ignore spaces though, but it adds them for you as you type. If you type in a VISA number it will format it as XXXX XXXX XXXX XXXX, but if you type in AMEX, it will format it as XXXX XXXXXX XXXXX. Pretty neat if you ask me. You can try it here http://codepen.io/anon/pen/WvygyO VISA: 4242 4242 4242 4242 AMEX: 3782 822463 10005 Diners: 3056 930902 5904 [0]https://stripe.com/blog/jquery-payment / https://github.com/stripe/jquery.payment
In The anatomy of a credit card form
Really neat! Any plans on open sourcing the formatting library? It's a good functionality, but (at least for me) would mainly be useful for view-layer on-the-fly formatting, and we wouldn't use an remote API request for that. Sort of like Strip's jQuery.payment[1], it would be a simple and clever marketing trick. People searching for a phone number formatting library are just the people you want to sell your services to. EDIT: just found libphonenumber, which does local formatting[2] [1] https://github.com/stripe/jquery.payment [2] https://github.com/googlei18n/libphonenumber
In Lookup by Twilio
But you're still up against freely available libraries that let a web developer build similar functionality, as as jquery.payment from the folks at Stripe: https://github.com/stripe/jquery.payment While it's not a completely like-for-like comparison, I suspect it will be tough to justify $299 per single web site for many businesses that might use these tools in the first place. Personally, I'd want solid data about conversion rates to back up the marketing on the creditcard.js website before I'd consider spending real money on anything like this.
In What was your best passive income in 2014?
Congratulations to the Stripe team. Strips is one of those excellent companies that make the tech world a better place. I actually spent the day working on adding Stripe integration to a Django application for my startup. Since there seem to be a number of Stripe people on this thread, I thought I might give some feedback. It was fairly straightforward to add a custom credit card form, but not as easy as I had expected. You've made a really nice form with Checkout, but that isn't flexible enough for many users. You leave a fair bit of work to your customers if they use the raw Stripe.js library. You mention your open source jquery library for doing client side validation [1], but don't provide any good examples. In particular, the neat trick in Checkout where you show the logo of the type of credit card being used isn't documented any
Read the rest
where. This blog post [2] is a crucial piece of information. Your Django examples seems a little out of date, as you've been using Flask for your python examples. In short, I spent a day pulling things together, and got a form that has many of the nice features of Checkout. That's cool. However, you should really make it dead simple for your customers, with good examples that give ultra-slick validation and results. Thanks for listening, and continue being great. [1] https://github.com/stripe/jquery.payment [2] http://yoast.com/checkout-field-validation/
In Payments Startup Stripe (YC S10) Joins the Billion Dollar Club
You make a good point, I'm not familiar with many of these libraries. Can you please provide some links. I'm familiar with: - Stripe jQuery.payment.js (formance is based on this project, extended beyond payment forms) https://github.com/stripe/jquery.payment - Masked Input (good for basic formatting, and does not include validating) https://github.com/digitalBush/jquery.maskedinput - Validate.js (does not include formatting) http://rickharrison.github.io/validate.js/
In Formance.js – Library for formatting and validating form fields
Many important parts of checkout are open-sourced via our jQuery.payment plugin [1]. It allows you to build your own checkout flow from component parts. As for open sourcing (capital C) Checkout entirely, we're working hard to provide a high-touch, consistent experience for checking out and we haven't been able to reconcile that with a bunch of small (maybe less thought-out) variations on the same thing floating around. We're always trying to think about ways to make this stuff better, though. We're definitely not against the idea, we just wanna do it right (i.e. allow non-programmers to customize without making things work incorrectly or look bad). 1. https://github.com/stripe/jquery.payment
In Open-Sourcing Stripe Shop
Full disclosure: I work on the team that implemented this feature. On Wave Invoices [1] we try to make it ridiculously easy for people to get paid. As such, we have a very select number of fields that are mandatory and don't require things like address, country, province, phone number, etc. Here is an example: http://i.imgur.com/yqSUMNb.png The payment amount is already filled in - set to the full amount of the invoice in question. The rest is relatively easy to fill out. We use the awesome jquery.payment [2] and Stripe.js [3] on this form so you get formatted input - like on the credit card number and expiry date - and inline validation. [1] https://www.waveapps.com/invoicing/ [2] https://github.com/stripe/jquery.payment [3] https://stripe.com/docs/stripe.js
In Why are payment forms so complicated?
At Stripe, we've had to take a lot of these considerations into account when designing the Checkout. One particular bug-bear of mine is people disabling autocomplete on their credit-card forms. Turns out that modern browsers (e.g. Safari/Chrome) encrypt CC data on disk, and that it's entirely PCI compliant to turn on autocomplete. The only field we don't do so (and that the browser doesn't store) is the CVC field. Another tip is adding 'pattern="\d*"' to number/cvc/expiry inputs. That'll bring up a numeric keyboard in mobile browsers. Lastly we've open sourced a library that'll do a lot of the client side validation and credit card number formatting for you: https://github.com/stripe/jquery.payment
In Why are payment forms so complicated?

Showing the 15 most recent of 17 sources. Enable JavaScript to search and browse every indexed mention.

MAKE YOURSELF AT HOME

A few shortcuts

/
Search the collection
?
Open this guide
Esc
Close dialogs and navigation

Your saved repositories and interests stay in this browser.