This is NOT the case. Stripe.createToken does very minimal checking of the card values. From Stripe, all it is doing is making sure the card number is long ENOUGH (not the right length) and passes the Luhn test. Adding extra digits to the card can result in a 200 response, even though the card number is not valid. Stripe.createToken only checks that the expiration date is in the future, not that it is the correct date associated with the card.
It is not UNTIL Customer.create that the card is actually determined to be a real, valid card. Therefore, Customer.create can fail with what Stripe has provided as a valid card token.
Try, for instance, what happens if you use card number:
if status == 200
$('#order_stripe_card_token').val(response.id)
$('#new_order')[0].submit()
clause in your script below?
coffeescript --yum
if response.error.message == "An unexpected error has occurred. We have been notified of the problem."
$('input[type=submit]').attr('disabled', false)
else
$('#stripe_error').text(response.error.message)
$('input[type=submit]').attr('disabled', false)
After you test for "An unexpected error..." or before?
I am testing on a legacy machine running XP (so IE 8) and not seeing the error. Should probably try on a machine running IE 10.
I cannot track down what I did (probably upgraded the Stripe API on our account), but as I worked back through my Stripe test logs, about 2 weeks ago each execution of:
in my coffee script started generating two tokens at the Stripe end, not one. Don't know if it is related because with FireFox (both XP and Mac) the "An unexpected error has occurred. We have been notified of the problem.", does not generate a token log entry (or 2) in the Stripe log, but :
js.coffee
handleStripeResponse: (status, response) ->
if status == 200
$('#order_stripe_card_token').val(response.id)
$('#new_order')[0].submit()
gets to the .submit() line, presumably because of a status ==200.
With Chrome, the error is there, but the token is in the hidden token field on the form and dismissing the error results in a new order being properly created. With FireFox, there doesn't seem to be anything in the hidden token field and order creation fails (but not by redirecting back to the "submit order" page.
I'm getting with Firefox (with subsequent failure to create to new entry--order in my case rather than subscription), Chrome (here the new entry is created...)
I've been using Bootstrap to build an e-commerce site, and have run into a font override issue that I cannot track down. Using Typekit fonts, I can easily override all the headings (h1-h6) by adding something like:
at the bottom of the bootstrap_and_overrides.css.less file. This generates the proper css in the final .css file that is served from the production server. These overrides are near, but not at, the bottom of the served .css file even though they are at the bottom of the bootstrap_and_overrides.css.less file. While overriding the headings works, I cannot override the body font. Using:
body {font-family: "proxima-nova",sans-serif;
font-style: normal;
font-weight: 300;}
generates the proper css near the bottom of the served .css file. Unfortunately, something else is adding a further body font-family override after thebootstrap_and_overrides.css.less override. There are 3 body font definitions in the served css; default Helvetica, followed by the "proximal-nova" assignment, which is then subsequently overridden by a Ventana assignment.
Any ideas where the Ventana assignment is coming from when using the twitter-bootstrap-rails gem? I've got the active admin gem bundled, but it appears to be doing styling on only active admin specific elements.
When you use a command like:
does .deliver return a result? That is, is:
valid code, and what, if anything, gets returned. I'm trying to figure out a way to catch an error if the smtp server is down.
One source of errors at my end was an assumption that card values (number, expiration, CVC) that passed a token request (returned 200):
return Stripe.createToken(card, order.handleStripeResponse);
would necessarily be a valid card token for:
This is NOT the case. Stripe.createToken does very minimal checking of the card values. From Stripe, all it is doing is making sure the card number is long ENOUGH (not the right length) and passes the Luhn test. Adding extra digits to the card can result in a 200 response, even though the card number is not valid. Stripe.createToken only checks that the expiration date is in the future, not that it is the correct date associated with the card.
It is not UNTIL Customer.create that the card is actually determined to be a real, valid card. Therefore, Customer.create can fail with what Stripe has provided as a valid card token.
Try, for instance, what happens if you use card number:
4242 4242 4242 4242 42
rather than:
4242 4242 4242 4242
Kobaltz,
Where are you putting the
clause in your script below?
After you test for "An unexpected error..." or before?
I am testing on a legacy machine running XP (so IE 8) and not seeing the error. Should probably try on a machine running IE 10.
I cannot track down what I did (probably upgraded the Stripe API on our account), but as I worked back through my Stripe test logs, about 2 weeks ago each execution of:
Stripe.createToken(card, order.handleStripeResponse)
in my coffee script started generating two tokens at the Stripe end, not one. Don't know if it is related because with FireFox (both XP and Mac) the "An unexpected error has occurred. We have been notified of the problem.", does not generate a token log entry (or 2) in the Stripe log, but :
gets to the .submit() line, presumably because of a status ==200.
With Chrome, the error is there, but the token is in the hidden token field on the form and dismissing the error results in a new order being properly created. With FireFox, there doesn't seem to be anything in the hidden token field and order creation fails (but not by redirecting back to the "submit order" page.
Are you seeing the error with all browsers?
I'm getting with Firefox (with subsequent failure to create to new entry--order in my case rather than subscription), Chrome (here the new entry is created...)
And not seeing the error with Safari or IE.
Argh!! Post something and then it becomes apparent...
scaffolds.css.scss is the last thing that generates content in the final served css...
I've been using Bootstrap to build an e-commerce site, and have run into a font override issue that I cannot track down. Using Typekit fonts, I can easily override all the headings (h1-h6) by adding something like:
h1 {font-family: "proxima-nova",sans-serif;
font-style: normal;
font-weight: 300;}
at the bottom of the bootstrap_and_overrides.css.less file. This generates the proper css in the final .css file that is served from the production server. These overrides are near, but not at, the bottom of the served .css file even though they are at the bottom of the bootstrap_and_overrides.css.less file. While overriding the headings works, I cannot override the body font. Using:
body {font-family: "proxima-nova",sans-serif;
font-style: normal;
font-weight: 300;}
generates the proper css near the bottom of the served .css file. Unfortunately, something else is adding a further body font-family override after thebootstrap_and_overrides.css.less override. There are 3 body font definitions in the served css; default Helvetica, followed by the "proximal-nova" assignment, which is then subsequently overridden by a Ventana assignment.
Any ideas where the Ventana assignment is coming from when using the twitter-bootstrap-rails gem? I've got the active admin gem bundled, but it appears to be doing styling on only active admin specific elements.