3 ms·

Nothing was mentioned about payment processors like Square, Stripe, Bluepay, Heartland, Authorize.Net, CCNow, Transfirst, etc. They have their disadvantages to

by vortico 10y ago

Nothing was mentioned about payment processors like Square, Stripe, Bluepay, Heartland, Authorize.Net, CCNow, Transfirst, etc. They have their disadvantages too, but the writer doesn't even evaluate them.

jimminy 10y ago
They were mentioned in the Credit/Debit card section just not by name. Mostly it's because they use proprietary code that the organization doesn't feel aligns with it's ethics. ". Most merchants outsource to third party card processing facilities (which won’t be mentioned here), typically redirecting to a page on that providers website, for accepting payments. The problem with this is that they often serve proprietary JavaScript"
- ploxiln 10y ago
  I appreciate what the FSF has done, and I generally appreciate their hard-line stance on free software issues ... but it's corner-cases like website javascript where I think they've gone off the rails. The browser running the javascript can be free/libre, the OS it is running on can be free/libre, the javascript language and browser environment is relatively standardized, it's sandboxed ... The JS is really just part of the page and/or service API. FSF doesn't have as big a problem calling banks that use closed-source telephony software or making api requests to closed-source webserver backends, there's really not that big a difference from a fully free/libre client interpreting a script in a standardized sandboxed environment, which it just received from a service, as part of using that service. The other odd FSF corner-case is that firmware blobs that you can't update are OK, but firmware blobs that you can update are not OK (even if they are freely redistributable). I'd say having a hardline stance on this is just not helpful.
  - webscaleizfun 10y ago
    Re: Javascript, all the FSF wants is a bright line for libre JS and proprietary JS & choice for what users want to run, and the ability to substitute in alternative javascript to replace the closed source JS on most sites. We're basically in the same place as Mono (Silverlight) and Shumway (Flash) did/could have ended up, where sure the engine to run the code is libre, but the code itself is not, and worse yet it is not clearly licensed. On firmware, the FSF has drawn a bright line on where hardware ends and software starts, and where they've drawn it is on whether firmware on device can be updated or not. If its not updatable, its a piece of hardware, plain and simple. If its updatable, then it is software, thus said code should be freely licensed and not Tivoized.
Teichopsia 10y ago
I hope this question is fine to ask, eternal beginner here. The few times I've looked for alternatives to stripe I'm inundated by choices and unfortunately, stripe doesn't work in my country. Nor is Atlas an option. What are good alternatives to them?
- ianlevesque 10y ago
  PayPal :( There's a reason people care enough to hate them.
  - Teichopsia 10y ago
    Same problem with PayPal. I can't get the money out. The closest I've been able to get was when I found a website a few weeks ago where I could buy game cards, gift cards. Doesn't help much when one wants to pay for bills and groceries. Is it too much to ask for a service that works in Central America?
    - kjax 10y ago
      The company I work for supports a ton of payment processor integrations, and Central and South America are always a bit rough for coverage. Depending on your country, Credomatic or Paguelofacil might work?
      - Teichopsia 10y ago
        Thanks, I'll look into those. Last year or so people here on HN were talking about a payment processor from Latin America (can't remember the name). The general consensus was not to trust it. I'll definitely look into those two, thanks again.
- clintonb 10y ago
  We are moving to Adyen (https://www.adyen.com/ https://www.adyen.com/).
analog31 10y ago
For my small business, that makes a non computer related gadget, I have a static web page and an order form that is a few dozen lines of plain HTML that I maintain in a text editor. It hasn't changed much in a few years, except to add new products and articles from time to time. So I don't have a web server or a reason to have one. I've looked into some of those services, though not all. Most of them seem to require me to maintain a Web server and to write back end code (hope I'm using the correct terminology) to route the customer's payment to the payment processor. This isn't something I know how to do, especially if I want it to be secure, and paying to have it done for me would be an expense. So it's PayPal for now until something better comes along. I check out the alternatives every year or so.
- derefr 10y ago
  It's the opposite, I think: most payment processors require you to have a web server to get the "invoice" after the customer pays—but certainly don't require you to route the customer's payment yourself, because that would violate PCI compliance (ideally, with these payment processors, you're not supposed to ever receive the customer's credit card information.)

by vortico 10y ago

jimminy 10y ago

They were mentioned in the Credit/Debit card section just not by name. Mostly it's because they use proprietary code that the organization doesn't feel aligns with it's ethics. ". Most merchants outsource to third party card processing facilities (which won’t be mentioned here), typically redirecting to a page on that providers website, for accepting payments. The problem with this is that they often serve proprietary JavaScript"

ploxiln 10y ago
I appreciate what the FSF has done, and I generally appreciate their hard-line stance on free software issues ... but it's corner-cases like website javascript where I think they've gone off the rails. The browser running the javascript can be free/libre, the OS it is running on can be free/libre, the javascript language and browser environment is relatively standardized, it's sandboxed ... The JS is really just part of the page and/or service API. FSF doesn't have as big a problem calling banks that use closed-source telephony software or making api requests to closed-source webserver backends, there's really not that big a difference from a fully free/libre client interpreting a script in a standardized sandboxed environment, which it just received from a service, as part of using that service. The other odd FSF corner-case is that firmware blobs that you can't update are OK, but firmware blobs that you can update are not OK (even if they are freely redistributable). I'd say having a hardline stance on this is just not helpful.
- webscaleizfun 10y ago
  Re: Javascript, all the FSF wants is a bright line for libre JS and proprietary JS & choice for what users want to run, and the ability to substitute in alternative javascript to replace the closed source JS on most sites. We're basically in the same place as Mono (Silverlight) and Shumway (Flash) did/could have ended up, where sure the engine to run the code is libre, but the code itself is not, and worse yet it is not clearly licensed. On firmware, the FSF has drawn a bright line on where hardware ends and software starts, and where they've drawn it is on whether firmware on device can be updated or not. If its not updatable, its a piece of hardware, plain and simple. If its updatable, then it is software, thus said code should be freely licensed and not Tivoized.

Teichopsia 10y ago

I hope this question is fine to ask, eternal beginner here. The few times I've looked for alternatives to stripe I'm inundated by choices and unfortunately, stripe doesn't work in my country. Nor is Atlas an option. What are good alternatives to them?

ianlevesque 10y ago
PayPal :( There's a reason people care enough to hate them.
- Teichopsia 10y ago
  Same problem with PayPal. I can't get the money out. The closest I've been able to get was when I found a website a few weeks ago where I could buy game cards, gift cards. Doesn't help much when one wants to pay for bills and groceries. Is it too much to ask for a service that works in Central America?
  - kjax 10y ago
    The company I work for supports a ton of payment processor integrations, and Central and South America are always a bit rough for coverage. Depending on your country, Credomatic or Paguelofacil might work?
    - Teichopsia 10y ago
      Thanks, I'll look into those. Last year or so people here on HN were talking about a payment processor from Latin America (can't remember the name). The general consensus was not to trust it. I'll definitely look into those two, thanks again.
clintonb 10y ago
We are moving to Adyen (https://www.adyen.com/ https://www.adyen.com/).

analog31 10y ago

For my small business, that makes a non computer related gadget, I have a static web page and an order form that is a few dozen lines of plain HTML that I maintain in a text editor. It hasn't changed much in a few years, except to add new products and articles from time to time. So I don't have a web server or a reason to have one. I've looked into some of those services, though not all. Most of them seem to require me to maintain a Web server and to write back end code (hope I'm using the correct terminology) to route the customer's payment to the payment processor. This isn't something I know how to do, especially if I want it to be secure, and paying to have it done for me would be an expense. So it's PayPal for now until something better comes along. I check out the alternatives every year or so.

derefr 10y ago
It's the opposite, I think: most payment processors require you to have a web server to get the "invoice" after the customer pays—but certainly don't require you to route the customer's payment yourself, because that would violate PCI compliance (ideally, with these payment processors, you're not supposed to ever receive the customer's credit card information.)