6 ms·

If there's no abstraction, what's your value-add? I don't care enough to read your marketing BS to see where you claim to be special, but... If your API is doin

If there's no abstraction, what's your value-add? I don't care enough to read your marketing BS to see where you claim to be special, but... If your API is doing the exact same things as an underlying service is doing, you're just a middleman extracting rents. You might find it more valuable to state your position as "carefully scoped abstractions" to make it clear what value you add.

koreth1 2y ago
Based on my previous experience on payment systems, there's a surprising amount of value in not having to maintain direct business relationships with the underlying payment providers. It is much, much easier to work with a company like Stripe than to work directly with Visa and MasterCard and the ACH network, and heaven help you if you're a small company that needs to do automated cross-border payments to a wide range of countries without a middleman. You'll probably also get much better support from a tech-focused company when an API starts freaking out.
- exe34 2y ago
  I thought I understood everything you said, but isn't Stripe a middleperson here? > without a middleman.
  - koreth1 2y ago
    Right, Stripe is a middleman and part of the value they're giving you is that you don't have to work directly with the underlying payment companies. If you had to support the same range of payment options without a middleman, you'd need to have business relationships with a bunch of payment companies, which would be a lot more difficult and time-consuming. Hope that's clearer!
    - exe34 2y ago
      Makes sense thanks!
  - OJFord 2y ago
    Yes, GP's point is 'good luck to you doing that yourself, without a middleman [such as Stripe]'.
- jackflintermann 2y ago
  Yes, exactly, the important thing to us is that our users don't need to build an additional mental model between us and the networks we sit atop. If you know the network, we want you to be able to intuit how our API works. There's a very real difference (arguably the fundamental value-add of our company) in the transport layer, though. The actual mechanics of integrating with, say, FedACH, are a bit long to get into here (we get into it a bit here if it's of interest: https://increase.com/documentation/fedach https://increase.com/documentation/fedach) but suffice to say it doesn't have a REST API.
  - koreth1 2y ago
    That's an excellent point too. Some payment systems have abysmal technology. The product I worked on was focused on international payments and in a couple cases, the "API" was literally, "Upload a CSV file via FTP, and at some later point, another CSV file might appear on the FTP server with some of the payment results, but if it doesn't, call us because we probably just forgot to upload it."
    - nijave 2y ago
      Batch jobs and (S)FTP. In a bit of a weird twist, back when I worked at Chase, they were innovating on the ancient technology but it was things like "better batch job management/orchestration" and SFTP proxy to route between different servers and centralize key management
  - jrochkind1 2y ago
    I'm curious to learn more about what your customers look like, what sorts of businesses and activities they are in. Where stripe's customers are working on products unrelated to payments, yours are working on products related to payments? I'm having trouble conceiving of examples.
  - wodenokoto 2y ago
    But it must have _some sort_ of API. Since your rest API is modelled on their API it made me really curious about how you communicate with those networks.
- fendy3002 2y ago
  Idk how this one works, but credit card processors need license. If you can use credit card service without requiring that license then it'll be the best additional value.
arrowsmith 2y ago
Presumably the value comes from providing a single unified platform that means you don't have to integrate with every underlying service separately. I know nothing about the lower-level details of payment networks but the mere fact that this company exists and has customers would suggest that there's a value-add.
conroy 2y ago
In this case, a HTTP API is the abstraction. Integrating with ACH and other payment rails requires a lengthy integration process. Sometime you have to send binary files using FTP!
- jiggawatts 2y ago
  The article says “no abstractions”, but HTTP is often exactly that: an abstraction over lower-level protocols.
  - jackflintermann 2y ago
    I guess the phrase "no abstractions" is specifically valuable to us when designing our REST API resources - our whole stack is certainly an abstraction of sorts, but we don't want to add yet another abstraction in that specific layer.
    - gr4vityWall 2y ago
      Just wanted to say that I appreciated the article :) Using well-designed APIs is great, and seeing people putting a lot of thought on it, with the intent of improving dev experience, is very refreshing. I've dealt a lot of technically impressive Free Software projects that didn't focus on this as much, and as a result, using their libraries was harder.
      - jackflintermann 2y ago
        Thank you!
  - chaos_emergent 2y ago
    perhaps what you're thinking of is "equal entropy abstractions" - HTTP is just a way of standardizing logic, but the complexity of the shape and behavior of the API remains.
  - gr4vityWall 2y ago
    My interpretation is that they meant domain-level abstractions. So, their API endpoints won't try to hide details about the underlying payment methods through abstractions, because that works best for those users. The API being implemented with JSON over HTTP isn't related to the domain of processing payments, so I don't see it as a contradiction to the article's title.
contravariant 2y ago
There is abstraction there's just not an additional layer of abstractions on top of it. Which to be honest is quite good, there's lots of things you can solve with an additional layer of abstraction but not having too many layers of abstraction. It's also rare to be able to identify an abstraction that correctly cuts things off at the right layer.
alex_lav 2y ago
> If there's no abstraction, what's your value-add? But then > I don't care enough to read Hmmmmmm.

koreth1 2y ago

Based on my previous experience on payment systems, there's a surprising amount of value in not having to maintain direct business relationships with the underlying payment providers. It is much, much easier to work with a company like Stripe than to work directly with Visa and MasterCard and the ACH network, and heaven help you if you're a small company that needs to do automated cross-border payments to a wide range of countries without a middleman. You'll probably also get much better support from a tech-focused company when an API starts freaking out.

exe34 2y ago
I thought I understood everything you said, but isn't Stripe a middleperson here? > without a middleman.
- koreth1 2y ago
  Right, Stripe is a middleman and part of the value they're giving you is that you don't have to work directly with the underlying payment companies. If you had to support the same range of payment options without a middleman, you'd need to have business relationships with a bunch of payment companies, which would be a lot more difficult and time-consuming. Hope that's clearer!
  - exe34 2y ago
    Makes sense thanks!
- OJFord 2y ago
  Yes, GP's point is 'good luck to you doing that yourself, without a middleman [such as Stripe]'.
jackflintermann 2y ago
Yes, exactly, the important thing to us is that our users don't need to build an additional mental model between us and the networks we sit atop. If you know the network, we want you to be able to intuit how our API works. There's a very real difference (arguably the fundamental value-add of our company) in the transport layer, though. The actual mechanics of integrating with, say, FedACH, are a bit long to get into here (we get into it a bit here if it's of interest: https://increase.com/documentation/fedach https://increase.com/documentation/fedach) but suffice to say it doesn't have a REST API.
- koreth1 2y ago
  That's an excellent point too. Some payment systems have abysmal technology. The product I worked on was focused on international payments and in a couple cases, the "API" was literally, "Upload a CSV file via FTP, and at some later point, another CSV file might appear on the FTP server with some of the payment results, but if it doesn't, call us because we probably just forgot to upload it."
  - nijave 2y ago
    Batch jobs and (S)FTP. In a bit of a weird twist, back when I worked at Chase, they were innovating on the ancient technology but it was things like "better batch job management/orchestration" and SFTP proxy to route between different servers and centralize key management
- jrochkind1 2y ago
  I'm curious to learn more about what your customers look like, what sorts of businesses and activities they are in. Where stripe's customers are working on products unrelated to payments, yours are working on products related to payments? I'm having trouble conceiving of examples.
- wodenokoto 2y ago
  But it must have _some sort_ of API. Since your rest API is modelled on their API it made me really curious about how you communicate with those networks.
fendy3002 2y ago
Idk how this one works, but credit card processors need license. If you can use credit card service without requiring that license then it'll be the best additional value.

arrowsmith 2y ago

Presumably the value comes from providing a single unified platform that means you don't have to integrate with every underlying service separately. I know nothing about the lower-level details of payment networks but the mere fact that this company exists and has customers would suggest that there's a value-add.

conroy 2y ago

In this case, a HTTP API is the abstraction. Integrating with ACH and other payment rails requires a lengthy integration process. Sometime you have to send binary files using FTP!

jiggawatts 2y ago
The article says “no abstractions”, but HTTP is often exactly that: an abstraction over lower-level protocols.
- jackflintermann 2y ago
  I guess the phrase "no abstractions" is specifically valuable to us when designing our REST API resources - our whole stack is certainly an abstraction of sorts, but we don't want to add yet another abstraction in that specific layer.
  - gr4vityWall 2y ago
    Just wanted to say that I appreciated the article :) Using well-designed APIs is great, and seeing people putting a lot of thought on it, with the intent of improving dev experience, is very refreshing. I've dealt a lot of technically impressive Free Software projects that didn't focus on this as much, and as a result, using their libraries was harder.
    - jackflintermann 2y ago
      Thank you!
- chaos_emergent 2y ago
  perhaps what you're thinking of is "equal entropy abstractions" - HTTP is just a way of standardizing logic, but the complexity of the shape and behavior of the API remains.
- gr4vityWall 2y ago
  My interpretation is that they meant domain-level abstractions. So, their API endpoints won't try to hide details about the underlying payment methods through abstractions, because that works best for those users. The API being implemented with JSON over HTTP isn't related to the domain of processing payments, so I don't see it as a contradiction to the article's title.

contravariant 2y ago

There is abstraction there's just not an additional layer of abstractions on top of it. Which to be honest is quite good, there's lots of things you can solve with an additional layer of abstraction but not having too many layers of abstraction. It's also rare to be able to identify an abstraction that correctly cuts things off at the right layer.

alex_lav 2y ago

> If there's no abstraction, what's your value-add? But then > I don't care enough to read Hmmmmmm.