HTTPay

A self-hosted, 0-conf payment processing proxy

Motivation

Information on the Internet has traditionally been made freely available (gratis). Content creators have long been expected to serve and continue serving their content altruistically, bearing any possible cost themselves. While this setup works well enough for small scale networks and niche content, the operational expenses can mount quickly, especially for popular services and content pieces. That is, in addition to the work that went into the creation of the content in the first place.

Information doesn't just "want" to be free. It also "wants" to be expensive.

The lack of a built-in content monetization mechanism is often cited as a major weakness in the traditional Web architecture, leading to the range of unhealthy behaviors that plagues it today (advertisements, tracking, consolidation and corporatization are a few examples).

What is needed is a voluntarist system of funding content creators, which would allow creators to sell and patrons to pay for content transparently and with minimal friction. This is such a system. It acts as middleware, transparently passing through user requests after payment was made.

But a payment processing proxy script alone is not enough. The issues that make the conventional payment system impractical in this context are fundamental to those conventional systems themselves. The need for a bank account and credit card creates barriers of entry and excludes major social groups (in particular, those under a certain arbitrary age) from participating in rewarding their favorite creators. The need to give away your payment details to make even the smallest of transfers opens the payer to all manner of fraud. On the creator's side, the need to enter a predatory contract with a payment processing company just to be able to receive payments or donations proves to be a constant source of stress. The payment processor acts as a middleman, with the power to stop, change or reverse any transaction or freeze the creator's account for an indefinite period of time without explanation or recourse, all while engaging in rent-extraction via numerous visible and hidden fees. The fees thus extracted impose a lower limit on the minimum viable transaction size, making small, casual payments (exactly the "rewarding creators" usecase) impractical.

Bitcoin Cash was invented specifically to solve the above problems. The peer-to-peer nature if its transactions, coupled with its negligible transaction fees, make it well-suited to the role of HTTPay's payment backend; And being simple and straightforward to build on, as well as being one of the most universally accepted cryptocurrencies with the highest rate of real-world adoption, makes it a perfect match.

Installation

You will need the following packages:

• Python 3.7 or later
• python-urllib3 - for detecting incoming payments
• python-qrcode - for generating payment request QR codes
• python-pillow - for generating payment request QR codes
• python-ecdsa - for cryptography
• python-base58 - for cryptography

Clone the project's git repository or download the release ZIP and extract it somewhere convenient. HTTPay will look for data files in the following locations:

• $HOME/.httpay
• $HOME/.config/httpay
• The same directory as the executable and the library files
• The current directory
• Failing all the above, $TEMPDIR (likely, /tmp)

Place the files to be paywalled inside the files directory in your data directory.

Place any files to be forwarded without requiring payment in the assets directory.

Copy httpay.cfg.sample to httpay.cfg and edit it to your preferences. In particular, provide an extended public key (xPub) for the wallet you wish to receive payments into.

HTTPay doesn't need a web server to run, as it provides its own. It also doesn't care what the URL used to access it looks like, and will happily serve its content on a bare IP address, a subdomain or a directory. However, if you wish it to be accessible on port 80 and integrated with your website, you will need to set up a reverse proxy. An example Nginx configuration is provided below:

upstream httpaydemo {
    server 127.0.0.1:8000 max_fails=3;
}

server {
#
# Some server configuration
#
    location ~ /httpay-demo/ {
        proxy_pass http://httpaydemo;
        proxy_cache off;
        proxy_set_header Host $host;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_pass_header Server;
    }
#
# More server configuration
#

Start the httpay executable, either manually, or using the provided SystemD service file, which also needs to be adjusted to your specific installation.

Edit the links on your website to any files which require payment to access to point to the location in the configuration you set up. For example, if the section of the site handling paywalled files is https://example.com/buy/, have your links point to https://example.com/buy/filename.ext.

Your paywall should be online and processing payments at this point.

Usage

Any visitors following a link in the above format will see a payment request page. Upon completing the payment, the requested file will be downloaded automatically. Returning visitors will be able to access the file previously paid for transparently as long as the cookie in their browser is valid (typically, until the browser is closed), which should be enough to allow the download of files. Authentication and proof-of-payment are not implemented.

Please note that the default settings are suitable for low use only and may run into block explorer API limits fairly quickly. If you plan on having a higher volume of purchases, consider running your own private block explorer instance.

Customization

You can integrate the payment request page into your website by placing a template.html file in your data directory, containing a complete page from your website, with all of its design and navigation intact. Place the string PAYMENT_REQUEST_BODY in the appropriate location in this page, on a line of its own. You can further style the payment request using CSS, by referencing the following selectors:

• #payment-request - the payment request container
• #payment-request p - the text of the payment request ("Unlocking...", "Please send..." and "Your file will be available...")
• #qrcode-container - the container of the payment request QR code
• #qrcode - the image of the payment request QR code
• #payment-request a - the payment request hyperlink, which can be opened in the Bitcoin Casah wallet

Other Notes

This program is free software, released under the Affero GNU GPL v3. See the LICENSE file for more information.

The release package ships the following libraries, with their own respective licenses:

• A stripped-down copy of CoinAddress - MIT license
• CashAddr - MIT license
• RIPEMD160 from BitCash - MIT license

The program's canonical project page resides at https://simonvolpert.com/httpay/

A live demo of the payment process can be seen at https://simonvolpert.com/buy/demo.html

Any payments made to this demo will be refunded back to the sending address within 24 hours of payment (processed manually). If you wish to have your payment NOT refunded, contact the author and provide as much information about the payment as possible.

Known Alternatives

The gmipay project, designed for the Gemini protocol instead. This version is much simpler, as the protocol itself handles the authentication, and there is no styling to consider. Some of the logic was adapted for use here.

Prompt.cash, a payment gateway service, offering post-payment callbacks to allow downloads and product order placement. Compared to Prompt, HTTPay is acting as the middleware itself, which means it is not possible to bypass the paywall by typing the direct URL to the file, and is fully self-hosted, meaning there are no privacy considerations at all.

WooCommerce/WordPress plugins: HTTPay does not require a WordPress installation and can work with static websites just fine. The only real requirement is the ability to run Python scripts on the server.