I liked this article a lot - information-dense but approachable. It feels like you can understand the entire app using only the code snippets in the article, which speaks to the quality of the design. The only part that made me roll my eyes was the AI piece - I don't think there's any actual AI involved in the app, it seems like the author just used it to figure out what metrics to use, and then hardcoded them into the app? (That's probably how I'd do it, tbh - I just think the AI part distracts from the overall point and doesn't need to be in the post.)
For deprecations we're lucky in that the underlying systems don't change very much (the Input Message Accountability Data isn't going anywhere). But we'll run into collisions when we, for example, start issuing cards on Mastercard as well as Visa.
We have experimented with a couple of, um, abstractions, and may do so there. One rule we've stuck to, and likely would as well, is to keep the "substrate objects" un-abstracted but to introduce higher-level compositions for convenience. For example, there is no such thing as a "Card Payment" (https://increase.com/documentation/api#card-payments) - it's just a way to cluster related card authorization and settlement messages. But it's extremely useful for users and nontrivial to do the reconciliation, so we tried it. But we think it's essential that the underlying network messages (the "substrate objects") are also accessible in the API, along with all the underlying fields etc.
Unfortunately 100% of the public APIs I have worked on are in payments. I wish I had another lens!
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.
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.
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) but suffice to say it doesn't have a REST API.
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."
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
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.
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.
I took a crack at recreating this in javascript once the necessary APIs made their way to mobile safari - https://highphone.app if interested! (iPhones only, sorry)
We took the approach of starting with an intentionally bad name (in our case, bnk.dev) and using it until a good domain became available to purchase for a reasonable price.
Neat idea overall! Some small feedback:
- You should check and see if the device has rotation lock enabled (or use a rotation API that isn't affected by it); I keep it on by default and the game wouldn't work for me until I thought to turn it off.
- It's pretty easy to accidentally tap an ad and thus destroy your game session.
Hello! Thanks for the tips! I recently found out that if the device is in rotation lock does not work, I'm already solving the problem. Soon I will release a second (the first is already in review, I added the game center, etc. ..) update with all these problems solved.
