Closed sethcall closed 8 years ago
We agree that this is a great feature!
For most cases, card numbers are either 16 digits split into 4 groups of 4 or it is an Amex card with a 4-6-5 structure.
There are other processors and international cards issuers who do not follow this pattern. To prevent an inconsistent and potentially confusing UX for our international merchants and users we decided to leave card formatting out of hosted-fields.
We may revisit this decision in the future, but at the current time there are no plans.
+1 for card formatting. Hosted fields promise SAQ-A without sacrificing user experience. This seems like a pretty big sacrifice.
I would also love to see this feature. The v.zero drop-in has it. Why can Hosted Fields not have it?
@mrak, re: "To prevent an inconsistent and potentially confusing UX for our international merchants and users we decided to leave card formatting out of hosted-fields."
Does that not apply to the v.zero drop-in also?
@RikdeBoer you are correct, it would have perhaps applied to drop-in had it been developed now.
Drop-in was initially released before we had a large international audience and before we supported many of the cards and issuers that were giving us formatting trouble with hosted-fields.
You will also notice that drop-in does not currently support internationalizations with the interface :(
As a result, for many of our merchants and users drop-in gives a good UX with formatting; but we have open tickets and support issues around drop-in with improperly handling and formatting certain card types.
We honestly do want to give you back your UX options with solutions like hosted-fields and make drop-in more international friendly, but we are a small front-end team working hard on many things.
No worries. I understand @mrak. Thank you for your explanation.
Any updates?
In short, this is on our roadmap.
This is actually a super tricky problem, but one that we are investing time to work on. Browsers handle user input events inconsistently and there are numerous edge cases to consider. There are a few libraries out there that provide input formatting (Formatter.js and jquery.inputmask, to name two) but they don't fit our use case for various reasons.
We really want to do this right and don't want to give you a half-baked version; we want to engineer this the right way. Not to make any promises, but this is something that we're working on. We will let you know as soon as we make headway.
Why not leverage Stripe's code where possible?
https://github.com/stripe/jquery.payment/blob/master/lib/jquery.payment.js
The license is very open: https://github.com/stripe/jquery.payment/blob/master/LICENSE
And they handle all sorts of cards and credit card lengths (it's not hardcoded to '16 digits').
We have this issue as well on a ecoommerce site and it causing sales to be lost clients have complained they can put the date on credit card. Is there a workaround or when is a fix going to be released?
@adstakt Input formatting is something we're actively working on adding to Hosted Fields. We'll update you here when it's released.
Hope it can be released soon. Thank you.
+1
We've released a beta of our next major version. This includes field formatting for things like expiration dates and credit card numbers.
Here are some links to our official documentation:
Setup for v3 Migrating from v2 to v3 Hosted Fields v3 demo with field formatting
Please send us any feedback on this new feature to js-sdk-beta@braintreepayments.com
Many websites now automatically space between every 4 numbers of the credit card field. This is a huge usability improvement, but the number field in the Hosted Fields iframe does not work this way, and AFAIK, does not support it.
It'd be great if this were supported!