The cost boundary
for tiny payments.

A small fixed processing charge can make a tiny payment uneconomic before the seller delivers anything. Published research compares how value-based and byte-based fee designs change that boundary.

A digital service can be worth a few cents: one piece of content, a small unit of data or a brief machine-to-machine interaction. The payment mechanism has to work at the same scale. A processing charge that looks modest on a larger purchase can consume the value of a small one.

My article, Empirical cost analysis of sub-dollar digital payments: Comparing legacy fee architectures with byte-denominated simplified payment verification, published in Results in Engineering, examines that structural problem. It compares direct processing fees across specified provider schedules and a controlled blockchain-based payment-verification implementation.

The fixed charge becomes the dominant term

A common fee formula combines a fixed charge with a percentage of the payment value. Divide that fee by the value transferred and the fixed part becomes larger as the payment gets smaller. A negotiated reduction can move the boundary, but any positive fixed charge continues to matter at a sufficiently small value.

The paper turns this into a threshold calculation. Given a target effective fee percentage and a specified schedule, what is the smallest payment that meets the target? The proportional rate sets one condition; the fixed charge determines how far the transaction value must rise above it.

The alternative studied prices a transaction by its data size. Its absolute fee depends on the number of bytes and the price per byte, rather than the amount of money being transferred. Its effective percentage still rises as payment value falls. The engineering opportunity is to make that absolute charge small enough to move the practical threshold far downward.

Compare the mechanisms on their stated terms

The study contains 55,000 fee evaluations spanning one cent to five dollars, with 11,000 for each provider. The four legacy-provider series are calculated from published fee schedules using generated transaction values. The Simplified Payment Verification, or SPV, series measures transactions executed in a dedicated Teranode test environment.

These are different evidence types. The legacy observations describe what the selected schedules charge; they are not a sample of live merchant payments. The SPV observations capture transaction-size variation at a configured fee rate. The test network had controlled mining and no competing fee bidders.

The rates are dated study inputs, including January 2024 platform schedules and derived card-network interchange parameters. Visa and Mastercard figures represent interchange rather than the full merchant discount rate. The comparison therefore needs its fee definitions and historical conditions attached, rather than being read as a current retail-pricing guide.

What the fee comparison shows

In the study’s one-cent-to-49-cent band, mean effective fees for the selected legacy schedules range from 38.43 percent for Mastercard to approximately 238 percent for the PayPal and Stripe schedules. The tested SPV implementation averages 0.06 percent. These are averages of fee percentages under the study’s sampled transaction values, rather than a single rate applied to every payment.

The threshold calculation provides a complementary view. Under the selected baseline parameters, reaching a five-percent effective-fee target requires roughly 1.42 dollars for Mastercard, 1.43 dollars for Visa and 14.29 dollars for PayPal or Stripe. The reported SPV threshold is approximately two-tenths of a cent.

The large difference comes from the absolute charge relative to transaction value. In the controlled SPV series, transaction size varies from 180 to 1,693 bytes, with an average of 388 bytes. The resulting average direct fee is approximately 0.000078 dollars at the study’s configured rate and exchange-rate conversion.

The regression analysis quantifies and checks the cost profiles rather than discovering the fee formulas. The mathematical structure already explains why the fixed charge dominates small payments. Changing the distribution of payment values can change the reported band averages without changing the threshold implied by a fixed schedule.

Test what can move the boundary

The paper examines sensitivity to higher SPV fee rates, legacy discounts, transaction size, interchange assumptions and exchange-rate changes. These exercises ask how much the numerical comparison moves when an input changes. They keep the architectural distinction between the amount transferred and the resources used to encode and process the transaction visible.

Network conditions require a separate assessment. The observed SPV fees come from an uncongested controlled environment. The manuscript adds an analytical congestion model under stated bidding assumptions, rather than treating the test fee as a guaranteed production price. Live workload, competing demand and the applicable fee mechanism remain relevant to deployment.

Likewise, a more complex transaction can require more bytes. Byte-denominated pricing makes that resource use part of the cost calculation. It does not make every transaction identical or remove the need to understand the construction used by a particular application.

A payment service includes more than its processing fee

The comparison isolates direct per-transaction charges. Fraud controls, compliance, consumer protection, dispute handling, integration and treasury management have to be assessed separately. The service bundles behind a merchant payment and an on-chain relay fee differ, so the raw fee gap is not a complete cost-of-ownership estimate.

The article also proposes a broader engineering assessment covering fee dispersion, independent verification requirements, response to load and confirmation reliability. These dimensions complement the cost calculation. They are not all like-for-like capabilities across the selected architectures, and a favourable result on one does not settle the others.

Low fees also raise an infrastructure question: can aggregate demand and the surrounding revenue model support long-term operation? The article leaves that as an empirical issue. A controlled demonstration of inexpensive processing cannot by itself establish sustained adoption or the economics of the complete service.

Design around the transaction the customer needs

The research connects payment engineering with transaction-cost economics and the design of digital services. If a product is naturally consumed in small increments, a fee architecture designed around larger purchases can constrain how it is sold. Bundling, subscriptions and prepayment may then reflect the payment mechanism as well as customer preferences.

The useful design question is explicit: for the intended transaction values, what direct fee does the architecture impose, which service costs remain outside that figure and how does the answer change under load? The paper supplies a structured way to examine that question. Its central result is that pricing the resources a transaction consumes can place the viable payment boundary at a very different scale from pricing its monetary value.