It should be noted that this is a pivot of a failed YC startup: http://blog.shoptheorem.com/post/109312542795/an-end-and-a-b...
Why should that be noted?
A vendor's history and potential obligations are important.
Show HN: Paid, an API for invoicing
11–20 of 37 posts
Re: Show HN: Paid, an API for invoicing
#12Earlier quoted context omitted.
It's really quick to start using. It's like a mashup of Segment and Stripe, you just start pinging events and it starts getting you money.
Could you integrate it with Xero? (Rather than relying on Zapier)
I'd love to hear why you don't want to rely on Zapier for this, any feedback?
Re: Show HN: Paid, an API for invoicing
#13I really like the clean API docs, well done! Did you build it on your own or is that some REST doc framework?
The only thing I was missing from the API (maybe those are there but left out in the docs, which would be totally fine) are links between your resources (to make it a bit more actual REST). You already more promimently documented the usecase ("create an invoice") instead of listing URL endpoints, but with links between the resources, the API becomes even more discoverable for new developers.
Oh, one more minor thing: "Paid uses UTC unix timestamps for all dates and times." -- I was under the impression that unix timestamps are always UTC anyway (i.e. it's defined as "seconds since 1970-01-01 UTC")? If I'm wrong, please correct me :)
Re: Show HN: Paid, an API for invoicing
#14Do they actually process charges? I can't find a cost / transaction and a % taken.
Re: Show HN: Paid, an API for invoicing
#15Do they actually process charges? I can't find a cost / transaction and a % taken.
Re: Show HN: Paid, an API for invoicing
#16Do they actually process charges? I can't find a cost / transaction and a % taken.
We use whatever payment processor you us. So, for example, you'd connect your Stripe account and we process all credit cards using that account. Our pricing is at www.paidapi.com/pricing and based of the revenue tracked/invoiced.
Re: Show HN: Paid, an API for invoicing
#17I really like the clean API docs, well done! Did you build it on your own or is that some REST doc framework? The only thing I was missing from the API (maybe those are there but left out in the docs, which would be totally fine) are links between your resources (to make it a bit more actual REST). You already more promimently documented the usecase ("create an invoice") instead of listing URL endpoints, but with lin…
The docs are an awesome repo by TripIt (https://github.com/tripit/slate). They aren't perfect, but they get you pretty far pretty quickly.
Not sure what you mean by "links between your resources." Have an example? May be there (or we can build it if not).
Correct on Unix time. Just being extra redundant.
Re: Show HN: Paid, an API for invoicing
#18Do they actually process charges? I can't find a cost / transaction and a % taken.
We use whatever payment processor you us. So, for example, you'd connect your Stripe account and we process all credit cards using that account. Our pricing is at www.paidapi.com/pricing and based of the revenue tracked/invoiced.
are u the gateway?
Re: Show HN: Paid, an API for invoicing
#19This is pretty cool. So, I am using Stripe, which is great, but has a few drawbacks right now. I'm also using churnbuster, which is nice (does your "chase" feature do what they do?)
Here's my problems:
1. Some of my customers pay by check
2. Sometimes my customers have an out of date credit card, or haven't given it to me yet, and Stripe won't let me change their subscription to one that charges them.
3. I occasionally do both charges, credits and invoiceitems for in Stripe
4. I have written a lot of Stripe specific code, and would prefer to gradually try out your solution (it might not work, no offense) Can I try it out without moving completely over?
Re: Show HN: Paid, an API for invoicing
#20It's just an invoicing program. There are lots of those. Intuit's is widely used. Oracle is also in that business. There's "Anytime Collect", "Zencash", "Esker", "Celtrino". and many others.
The more advanced players support electronic data interchange (EDI), where your accounts receivable system connects to the buyer's accounts payable system. Many large companies require EDI for suppliers who generate a lot of invoices, so they aren't re-entering invoice data into their own systems.[1] Any new system should have EDI interchange with at least all Fortune 1000 companies.
There are "gateway" companies which handle talking to large numbers of other companies.[2] Once you get this all working, your invoice goes out to the gateway, the gateway formats it and sends it to the paying company, the paying company's systems validate the bill, and they do a funds transfer to your bank account, which is matched to another EDI transaction indicating payment. For most routine transactions, there's no human intervention.
Make that all work for small/medium businesses, and you have a unique product.
The API is "dead simple" because it doesn't handle any of the hard cases. Like "We ordered 1000 but 200 didn't arrive. We're paying for only 800".
[1] http://www.aepedi.com/apay.htm [2] http://www.b2bgateway.net/