5 ms·

Recurly.js library released for secure, customizable checkout forms

124 points by danburkhart 15y ago

Hovertruck 15y ago
This is nice, but I sort of wish it stated more bluntly that it requires jQuery. I also wish it didn't depend on jQuery, but that's just personal preference.
- emery 15y ago
  I'm the author. I'll be sure to put a notice at the top of the readme that it requires jQuery. Also, I agree with you. The jQuery dependency will be removed eventually. It was a time saver in the short term as we do a lot of DOM manipulation.
  - arfrank 15y ago
    FYI: There are error in the display of the blogpost announcing it at: http://blog.recurly.com/ http://blog.recurly.com/
  - krosaen 15y ago
    I'm a paying recurly customer, and I think depending on jQuery is totally fine; even if we had to include jQuery on a payment page when we didn't use it anywhere else on our site, that wouldn't be any trouble. Please, use your precious development time on more pressing issues related to making payment's even easier to accept and integrate!
pbreit 15y ago
PayPal should have been doing this years ago. Kudos to Recurly for bringing this to the public in front of Stripe which is still private.
- sfjustin 15y ago
  CheddarGetter has had this feature for awhile.
  - pbreit 15y ago
    I just looked and wasn't able to find it. For one, CheddarGetter looks to be a hosted provider whereas Recurly and Stripe support buyers remaining on the merchant's web pages. But the main feature I was referencing was a JavaScript library that handles credit card information so that the merchant never sees a credit card number and thus need not worry about PCI compliance. That historically has not been provided in a way that allows the payer to remain on the merchant's web page.
    - jcc80 15y ago
      I think Braintree does it, kind of: "By using our Transparent Redirect (TR) and Vault, merchants can achieve PCI Compliance in days. TR and the Vault will eliminate the handling, processing or storing credit card data so you can qualify for the Self Assessment Questionnaire A, the shortest of the four SAQs." http://www.braintreepayments.com/services/pci-compliance http://www.braintreepayments.com/services/pci-compliance edit: So, w/ Recurly I wonder if it's the same thing and I'd need to do the Self Assessment Questionnaire A when using recurly.js
      - isaachall 15y ago
        With Recurly.js and our Transparent Post, merchants only need to fill out the Self Assessment Questionnaire A. We launched our own Transparent Post back in March 2011. We created Recurly.js to simplify performing client-side validation, pricing calculations (w/ coupons, VAT, add-ons), and proper error handling when a transaction is declined. It's 10x easier to implement than Transparent Post, and has a much better user experience for the customer.
        jcc80 15y ago
        Thanks for spelling that out for me. As for being simple - I have begun teaching myself somewhat recently while looking for a good match w/ someone more technical. I can really only handle html & css at this point - sad I know. Anyways, this was very easy for me to setup. I've already got it going on my site w/ sandbox account. But, going to hold off for now and just use hosted payment pages for a bit. Will likely use this in the near future though - thanks to the Recurly team.
trungonnews 15y ago
How is this PCI compliance? You're exposing credit card number on the input field of the original publisher's HTML page. This means that the publisher can pick up the credit card number himself, or an included third party javascript library(like google analytics).
- isaachall 15y ago
  The Recurly.js library dramatically reduces PCI compliance scope because the sensitive cardholder data does not pass thru your servers. There's a lot of additional PCI compliance issues when the credit card numbers pass thru your server, even if it only resides in memory during the request. Instead, the data is sent directly from the web browser to Recurly, who is PCI Level 1 Compliant. Obviously, you still have to maintain a secure web server regardless of how you collect payments. That means protecting your users from cross site scripting.
  - drivebyacct2 15y ago
    ... which thus precludes the security (and thus simplicity) aspect of Recurly.js.
    - pbreit 15y ago
      Recurly still supports hosted payment pages in which case the merchant doesn't need SSL. As far as I know, Recurly and Stripe are the only two processors providing JavaScript libraries to tokenize credit card information such that merchants do not handle the credit card information that suscepts them to PCI compliance.
      - trungonnews 15y ago
        socialgold had a similar product before google acquired it.
  - trungonnews 15y ago
    You're missing the point. While the user is entering the credit card number, there's a chance that someone can intercept and steal the CC. You can easily solve this problem by putting the credit card form inside your own iframe. :)
BSeward 15y ago
Is this accessible for audio browsers? Screen readers navigating by form elements will be pretty lost without <label>s (and WAI-ARIA attributes for rich components, but one thing at a time). Would hate to be the site that tried to simplify their billing but got an accessibility lawsuit[1] for their troubles. [1]: http://en.wikipedia.org/wiki/National_Federation_of_the_Blind_v._Target_Corporation http://en.wikipedia.org/wiki/National_Federation_of_the_Blin...
- mtogo 15y ago
  Wow, thanks for linking that lawsuit. I had no idea there was a risk of getting sued just for not setting your site up perfectly for primadonna blind persons. That's really terrifying.
  - fletchowns 15y ago
    > primadonna blind persons What a hateful, insensitive thing to say. Obviously the National Federation of the Blind isn't going to go after just any website, they are going to go after the larger ones that should know better. Big companies should absolutely be forced to accommodate people with disabilities, I would even say that is part of what makes the United States such a great country.
    - deleted 15y ago
      [deleted]
    - deleted 15y ago
      [deleted]
voxmatt 15y ago
This is very nicely done. I would like to see a long-form explanation from Recurly about the safety implications of this, however. Maybe it really is brilliantly bullet-proof, but please explain.
isaachall 15y ago
PCI compliance is about maintaining a secure network, transmitting information securely, logging access in case of a breach, and access controls. Recurly.js minimizes your compliance scope because the sensitive data does not pass thru your network. You are still required to maintain a secure network so that malicious code does not end up on your site. This means protecting your site from cross-site scripting. If your site is running untrusted Javascript code, your users could end up being redirected to a phishing site regardless of how you implement your order form (including linking offsite to a hosted page). As long as your server is secure, Recurly.js is secure. The one scenario that is being pointed out here is from a malicious merchant. We work to make it easier for a merchant to be PCI compliant. If they are malicious and want to defraud their own customers, there are easier ways to post the credit card numbers straight to your server without our software.
- grimen 15y ago
  At Merchii we have solved this in similar fashion, but we actually don't need to care if the host site is secure or not - we take care of that too (completely secure).
- trungonnews 15y ago
  If you're going to advertise Recurly as a secured payment product, then you need to do everything you can to prevent third parties and the merchant from peeking at your credit card form. On any given web page, it can easily bring in 10 or more external JS libraries. So the chance of one of them getting compromised can only go higher. You need to make sure that your product can survive a cross site scripting attack. And you need to protect your product against your own merchant because those misbehaved merchants can give your business a bad name. Let them steal their users' credit card, but just don't let them steal it from Recurly's credit card form... You could have solved these two security issues if you spend a little more effort and put the credit card form inside Recurly owned iframe. But I guess your engineering team took a short cut. :)
  - grimen 15y ago
    Yes in fact the iframe is the only way of doing it securely with the current web specs. ...and it can in fact be done almost completely seamless for the end user, with lil bit of hacking.
simonw 15y ago
The http://js.recurly.com/ http://js.recurly.com/ site doesn't link to or mention recurly.com (or that it's a payment provider service) anywhere. As a result, I was pretty confused when the intro video started mentioning the "Recurly API" - I was also wondering how an open source JavaScript form library could possibly handle payments. Suggestion: add the text "a JavaScript library for the Recurly payments API" (or equivalent) somewhere on the page!
kposehn 15y ago
...this is awesome. Thanks Recurly, you just saved my new product a ton of time!

124 points by danburkhart 15y ago

This is nice, but I sort of wish it stated more bluntly that it requires jQuery. I also wish it didn't depend on jQuery, but that's just personal preference.

emery 15y ago
I'm the author. I'll be sure to put a notice at the top of the readme that it requires jQuery. Also, I agree with you. The jQuery dependency will be removed eventually. It was a time saver in the short term as we do a lot of DOM manipulation.
- arfrank 15y ago
  FYI: There are error in the display of the blogpost announcing it at: http://blog.recurly.com/ http://blog.recurly.com/
- krosaen 15y ago
  I'm a paying recurly customer, and I think depending on jQuery is totally fine; even if we had to include jQuery on a payment page when we didn't use it anywhere else on our site, that wouldn't be any trouble. Please, use your precious development time on more pressing issues related to making payment's even easier to accept and integrate!

pbreit 15y ago

PayPal should have been doing this years ago. Kudos to Recurly for bringing this to the public in front of Stripe which is still private.

sfjustin 15y ago
CheddarGetter has had this feature for awhile.
- pbreit 15y ago
  I just looked and wasn't able to find it. For one, CheddarGetter looks to be a hosted provider whereas Recurly and Stripe support buyers remaining on the merchant's web pages. But the main feature I was referencing was a JavaScript library that handles credit card information so that the merchant never sees a credit card number and thus need not worry about PCI compliance. That historically has not been provided in a way that allows the payer to remain on the merchant's web page.
  - jcc80 15y ago
    I think Braintree does it, kind of: "By using our Transparent Redirect (TR) and Vault, merchants can achieve PCI Compliance in days. TR and the Vault will eliminate the handling, processing or storing credit card data so you can qualify for the Self Assessment Questionnaire A, the shortest of the four SAQs." http://www.braintreepayments.com/services/pci-compliance http://www.braintreepayments.com/services/pci-compliance edit: So, w/ Recurly I wonder if it's the same thing and I'd need to do the Self Assessment Questionnaire A when using recurly.js
    - isaachall 15y ago
      With Recurly.js and our Transparent Post, merchants only need to fill out the Self Assessment Questionnaire A. We launched our own Transparent Post back in March 2011. We created Recurly.js to simplify performing client-side validation, pricing calculations (w/ coupons, VAT, add-ons), and proper error handling when a transaction is declined. It's 10x easier to implement than Transparent Post, and has a much better user experience for the customer.
      - jcc80 15y ago
        Thanks for spelling that out for me. As for being simple - I have begun teaching myself somewhat recently while looking for a good match w/ someone more technical. I can really only handle html & css at this point - sad I know. Anyways, this was very easy for me to setup. I've already got it going on my site w/ sandbox account. But, going to hold off for now and just use hosted payment pages for a bit. Will likely use this in the near future though - thanks to the Recurly team.

trungonnews 15y ago

How is this PCI compliance? You're exposing credit card number on the input field of the original publisher's HTML page. This means that the publisher can pick up the credit card number himself, or an included third party javascript library(like google analytics).

isaachall 15y ago
The Recurly.js library dramatically reduces PCI compliance scope because the sensitive cardholder data does not pass thru your servers. There's a lot of additional PCI compliance issues when the credit card numbers pass thru your server, even if it only resides in memory during the request. Instead, the data is sent directly from the web browser to Recurly, who is PCI Level 1 Compliant. Obviously, you still have to maintain a secure web server regardless of how you collect payments. That means protecting your users from cross site scripting.
- drivebyacct2 15y ago
  ... which thus precludes the security (and thus simplicity) aspect of Recurly.js.
  - pbreit 15y ago
    Recurly still supports hosted payment pages in which case the merchant doesn't need SSL. As far as I know, Recurly and Stripe are the only two processors providing JavaScript libraries to tokenize credit card information such that merchants do not handle the credit card information that suscepts them to PCI compliance.
    - trungonnews 15y ago
      socialgold had a similar product before google acquired it.
- trungonnews 15y ago
  You're missing the point. While the user is entering the credit card number, there's a chance that someone can intercept and steal the CC. You can easily solve this problem by putting the credit card form inside your own iframe. :)

BSeward 15y ago

Is this accessible for audio browsers? Screen readers navigating by form elements will be pretty lost without <label>s (and WAI-ARIA attributes for rich components, but one thing at a time). Would hate to be the site that tried to simplify their billing but got an accessibility lawsuit[1] for their troubles. [1]: http://en.wikipedia.org/wiki/National_Federation_of_the_Blind_v._Target_Corporation http://en.wikipedia.org/wiki/National_Federation_of_the_Blin...

mtogo 15y ago
Wow, thanks for linking that lawsuit. I had no idea there was a risk of getting sued just for not setting your site up perfectly for primadonna blind persons. That's really terrifying.
- fletchowns 15y ago
  > primadonna blind persons What a hateful, insensitive thing to say. Obviously the National Federation of the Blind isn't going to go after just any website, they are going to go after the larger ones that should know better. Big companies should absolutely be forced to accommodate people with disabilities, I would even say that is part of what makes the United States such a great country.
  - deleted 15y ago
    [deleted]
  - deleted 15y ago
    [deleted]

voxmatt 15y ago

This is very nicely done. I would like to see a long-form explanation from Recurly about the safety implications of this, however. Maybe it really is brilliantly bullet-proof, but please explain.

isaachall 15y ago

PCI compliance is about maintaining a secure network, transmitting information securely, logging access in case of a breach, and access controls. Recurly.js minimizes your compliance scope because the sensitive data does not pass thru your network. You are still required to maintain a secure network so that malicious code does not end up on your site. This means protecting your site from cross-site scripting. If your site is running untrusted Javascript code, your users could end up being redirected to a phishing site regardless of how you implement your order form (including linking offsite to a hosted page). As long as your server is secure, Recurly.js is secure. The one scenario that is being pointed out here is from a malicious merchant. We work to make it easier for a merchant to be PCI compliant. If they are malicious and want to defraud their own customers, there are easier ways to post the credit card numbers straight to your server without our software.

grimen 15y ago
At Merchii we have solved this in similar fashion, but we actually don't need to care if the host site is secure or not - we take care of that too (completely secure).
trungonnews 15y ago
If you're going to advertise Recurly as a secured payment product, then you need to do everything you can to prevent third parties and the merchant from peeking at your credit card form. On any given web page, it can easily bring in 10 or more external JS libraries. So the chance of one of them getting compromised can only go higher. You need to make sure that your product can survive a cross site scripting attack. And you need to protect your product against your own merchant because those misbehaved merchants can give your business a bad name. Let them steal their users' credit card, but just don't let them steal it from Recurly's credit card form... You could have solved these two security issues if you spend a little more effort and put the credit card form inside Recurly owned iframe. But I guess your engineering team took a short cut. :)
- grimen 15y ago
  Yes in fact the iframe is the only way of doing it securely with the current web specs. ...and it can in fact be done almost completely seamless for the end user, with lil bit of hacking.

simonw 15y ago

The http://js.recurly.com/ http://js.recurly.com/ site doesn't link to or mention recurly.com (or that it's a payment provider service) anywhere. As a result, I was pretty confused when the intro video started mentioning the "Recurly API" - I was also wondering how an open source JavaScript form library could possibly handle payments. Suggestion: add the text "a JavaScript library for the Recurly payments API" (or equivalent) somewhere on the page!

kposehn 15y ago

...this is awesome. Thanks Recurly, you just saved my new product a ton of time!