Hacker Newsnew | past | comments | ask | show | jobs | submit | faxman's commentslogin

I'm working on PayPerFax - https://payperfax.com/ - a simple online faxing service that lets individuals send faxes without committing to subscriptions or creating accounts.

The idea came from an interesting "tail wagging the dog" situation. I had an old domain (faxbeep.com) lying around unused which I'd been renewing for 20 years. When I finally built something there, I discovered users were more interested in a fax testing feature that I'd added as an afterthought - the abitlity to send a fax to our test numbers and see it appear on the website for 30 days.

That insight led me to dedicate faxbeep.com entirely to fax testing, and to buy payperfax.com for my original idea: straightforward, pay-as-you-go faxing. People still need to send faxes surprisingly often - for tax authorities, immigration paperwork, medical prescriptions, etc. The service charges a fixed fee for a 3-page fax (cover + 2 pages) with a bit more for additional pages, and you only pay if the fax sends successfully.

My current challenge is visibility - Google has essentially black-holed the site. Even exact match searches like [pay per fax] don't bring up the site. If anyone has SEO advice on how to climb out of this hole - I'd appreciate it!


True, but then, taken to its logical conclusion, isn't everything just "things that emerge in an observer's model of the world", e.g., an ant, a chair, a rock?


Healthcare providers have been entrusting their faxing to outside service providers for quite a while now, without on-premise installations.


Any reasonable fax service provider will allow reception of multiple faxes concurrently. Some might deliberately limit the number of concurrent connections so that one client's activity doesn't kill their other clients, but even that sort of throttling would in practice be a very rare event.


Your description is right. To give this a visual dimension, here are sequence diagrams showing how outbound and inbound faxing work at another provider (disclaimer: I'm a co-founder at Interfax):

Outbound: https://www.interfax.net/en/dev/dev-guide/using-interfax-for...

Inbound: https://www.interfax.net/en/dev/dev-guide/using-interfax-for...

Your suggestion for a "sign this and send it back" workflow is an excellent idea. Indeed it shouldn't require more than a single fax number per client, leaving the barcode to do any necessary association. But I would say that this functionality is not best placed on the fax service provider's system, but rather in the application that creates the document to be signed and eventually receives it back. Here's what I mean: http://imgur.com/a/JEldx


Thanks for the sequence diagram. That's exactly what we're doing.


You might want to take a look our service, Interfax, an API-powered internet fax service provider, which addresses HIPAA and offers BAA's.

In fact, we cover a range of regulatory/standard requirements such as PCI-DSS (Tier 1) and EU GDPR.

We're now also looking at the Oz equivalent of these types of legislation.

https://www.interfax.net/en/hipaa_compliance


I'm only familiar with RightFax in the EHR world. How does Interfax compares to it (are they even filling the same need)?


InterFAX is the SaaS version of RightFax. No installation of hardware, software, or phone lines required. (But, as with any Saas, trust in the vendor is necessary).


> only maintain libraries for your SOAP endpoint (at least for now

Check. This was the decision that came out of today's product meeting after reading responses here.

> Put up a form...

Check. Already did this a couple weeks ago at www.interfax.net/en/dev/rest. Already got a few bites.

> Just because someone on a survey said they wanted REST instead of SOAP ...

I agree. However, we ran several variations of the survey including one where developers had an opportunity to say that not having REST is a show-stopper for them, which got us worried.

Strangely, most of those who insisted on REST develop in environments which have the strongest SOAP support, like C#, PHP, and Java. This got me thinking that we might be dealing with fashion issues more than practical issues...


> ... conditioned to vote for REST over SOAP.

Yes, I dread to think I'm going through a lengthy project just to address a current fashion trend...


> If you're always providing API access through a proprietary library, > it doesn't matter if it's REST, SOAP, custom binary protocols, or whatnot.

That was exactly my thought. I was looking for reinforcement of the possibility that people will still want the entire REST interface visible and documented even in the presence of wrapper libraries.


Personally, I prefer REST interfaces, because it always seems like vendor libraries have just enough suck in them to make me want to use my own.


Actually, moving to REST requires you to change your head around from a procedural point of view to one dealing in objects and operations, so it won't be a direct mapping of SOAP to REST.


Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: