Building FaxOnWeb: A Pay-As-You-Go Online Fax Service Without a Subscription

FaxOnWeb is a pay-as-you-go online fax service built for people who need to send an outbound fax without creating an account or starting a subscription. This article explains why the service separates PayPal authorization from capture and waits for confirmed delivery before completing payment.

 

Most online fax services are built around the assumption that faxing is an ongoing need. For many people, it is not.

Someone may need to send a signed document to a government office, an insurer, a bank, or another business. Once that document is delivered, they might not send another fax for months. Creating an account and starting a subscription for that one task feels like the wrong default.

I built FaxOnWeb around a narrower idea: let people send an outbound fax from a browser, pay for that fax once, and follow it until the receiving fax machine reports a final result.

Disclosure: I built and operate FaxOnWeb. This article explains the product decisions and engineering lessons behind the service.

FaxOnWeb provides one-time online fax sending with PayPal and no monthly subscription.

Keeping the product deliberately narrow

The basic workflow is straightforward:

1. Upload a document.
2. Choose the destination country.
3. Enter the recipient’s fax number.
4. Review the price.
5. Authorize the payment with PayPal.
6. Wait for the final delivery result.

There is no FaxOnWeb account to create and no monthly plan to cancel later. At the time of writing, the price is USD 2.89 for up to five pages, followed by USD 0.39 for each additional page.

That simple interface hides a less simple problem. A fax transmission and a payment do not finish at the same time, and neither of them can safely be treated as a single request.

A PayPal authorization is not the same as a charge

The easiest payment flow would be to charge the customer as soon as they click the PayPal button. It would also create an unpleasant failure case: the payment could succeed even though the receiving fax machine never accepts the document.

FaxOnWeb separates authorization from capture.

PayPal first authorizes the amount shown in the browser. This confirms that the payment can proceed, but it is not treated as the final charge. FaxOnWeb submits the fax and waits for the delivery result. The authorized payment is captured only after the provider confirms successful delivery.

If the transmission reaches a final failure instead, the service starts an attempt to void an open authorization or refund an existing capture. Any unresolved payment recovery still needs to remain visible for reconciliation rather than being hidden behind a generic error message.

This makes the state model more complicated, but the customer-facing rule stays understandable:

Successful delivery leads to capture. Final failure leads to a void or refund attempt.

Each fax has one visible price, while authorization, capture, and failure recovery remain separate states.

“Accepted” does not mean “delivered”

Fax providers often acknowledge that a job has been accepted for processing. That acknowledgment is useful, but it is not proof that the receiving fax machine got the document.

The remote line might be busy. The destination might not answer. The transmission could fail after the provider has already accepted the job.

For that reason, FaxOnWeb treats provider acceptance as an intermediate state. The service continues tracking the job until it receives a final success or failure result.

That distinction also affects the language shown in the browser. A status such as “submitted” or “accepted” should not quietly turn into “delivered.” The user should be able to tell whether the document is still being processed or has actually reached the receiving machine.

This sounds like a wording detail, but it is part of the transaction model. A misleading status can be just as damaging as a technical error when someone is sending an important document.

FaxOnWeb tracks payment and delivery independently until the fax reaches a final outcome.

The difficult part is recovery, not the happy path

Uploading a file and opening PayPal are not the hardest parts of the system. The difficult cases happen between steps.

A browser can close after payment authorization. A network response can disappear even though the server completed the request. A provider result may arrive later than expected. The same callback can be delivered more than once. A user may refresh the page while the fax is still pending.

These cases require the service to keep payment, document, and delivery states separate. Retrying a browser request must not create a second payment or submit the same document twice. A delayed provider result must still be associated with the correct transmission attempt. Recovery also needs to preserve enough state to show the user what happened without exposing unnecessary document or payment details.

The useful lesson was simple: for this kind of service, the state machine is not an implementation detail. It is the product.

Fax documents need a different level of care

Fax is still used for documents that people do not want exposed casually. The service therefore has to treat the uploaded file as sensitive even when it is not making a claim about any particular regulatory certification.

FaxOnWeb accepts PDF, TIF, TIFF, JPG, JPEG, and PNG files. A fax can contain up to 200 pages, with a combined upload size of up to 20 MB.

Documents are protected with TLS while in transit. Files retained while the service waits for the final delivery result are encrypted at rest with AES-256-GCM. Validation and transmission use isolated, short-lived processing files rather than relying on a permanently readable copy.

Deletion is attempted after confirmed delivery. For a final failure, deletion is attempted no later than seven days after upload, and failed deletion operations are retried. If a delivery or retention outcome is still unresolved, the retained copy remains encrypted while the service reconciles the final state.

These controls are not presented as a blanket claim of HIPAA, GDPR, or any other certification. A technical safeguard and a regulatory certification are not interchangeable, and the product should not suggest otherwise.

What FaxOnWeb does not provide

It is tempting to turn a focused service into a full fax platform, but the missing features are intentional.

FaxOnWeb does not provide:

• A receiving fax number
• A virtual fax number
• Fax-to-email receiving
• Email-to-fax sending
• Broadcast or bulk faxing
• A monthly subscription plan

It sends one outbound fax at a time through the browser. That boundary keeps the checkout and delivery workflow easier to understand, and it avoids presenting features that the service does not actually support.

The same principle applies to destination support. The checkout country selector is the source of truth for the destinations currently available. Country selection helps format the number, but the sender is still responsible for confirming that the number belongs to the intended recipient.

Why the small scope matters

A one-off fax service does not need to imitate an enterprise communications suite.

Its job is narrower:

• Make the price visible before payment
• Avoid forcing a subscription
• Keep authorization separate from final capture
• Distinguish provider acceptance from confirmed delivery
• Protect the document while it is needed
• Report failures honestly
• Preserve enough state to recover from interrupted browser sessions

A smaller feature set does not make the engineering trivial. It makes the promises easier to state precisely.

If you need to send an occasional outbound fax, you can review the current pricing and payment flow on the pay-as-you-go online fax service.

FaxOnWeb also provides a free browser-based fax cover sheet generator.

The cover sheet generator keeps entered fields in the browser and provides a live preview.

The cover sheet fields stay in the browser tab and can be printed or saved as a PDF before being added to the fax document.