• Release 1.0.32
Boriable
Boringly Reliable Crypto Payments for FluentCart
It started innocently enough.
We wanted FluentCart to accept TRX.
Not “integrate a giant crypto-payment processor.” Not “send customers to somebody else's checkout.” Not “open an account with a custodian who holds the merchant's cryptocurrency.”
Just:
Customer chooses crypto. Customer sends crypto directly to the merchant's wallet. FluentCart knows when the money arrived.
How hard could that possibly be?
Several murdered assumptions, one dead Schrödinger's cat, a Cloudflare D1 database, multiple blockchain APIs, a licensing server, quite a few ten-cent transactions and an unreasonable number of codenames later, Boriable 1.0 exists.
And the architecture that emerged is considerably more interesting than the original TRX gateway.
The fundamental design decision: Boriable never holds the money
Boriable is non-custodial.
The merchant enters public receiving addresses for the cryptocurrencies they want to accept. The customer sends directly to those addresses.
Boriable never possesses:
There is no Boriable wallet sitting between customer and merchant.
That immediately eliminates an entire category of custody and withdrawal problems.
It creates another problem, though:
How does WordPress know that somebody actually paid?
Trusting the browser is obviously out.
Trusting a callback originating from the browser is out.
And allowing every merchant's WordPress installation to be the ultimate authority on blockchain settlement didn't appeal to us either.
So Boriable acquired a second half.
WordPress is the client. Boriable is the verifier.
The production architecture became:
Customer
│
│ creates FluentCart order
▼
WordPress + FluentCart + Boriable plugin
│
│ registers expected payment
▼
Boriable Verifier
Cloudflare Worker + D1
│
├── TRON
├── Ethereum
├── BNB Chain
├── Polygon
├── Solana
├── Litecoin
├── Ripple
└── Bitcoin
│
▼
Blockchain transaction detected and confirmed
│
│ signed HMAC callback
▼
Merchant WordPress
│
▼
FluentCart transaction PAIDThe distributed WordPress plugin therefore isn't the security perimeter.
The verifier is.
A WordPress installation can request a payment watch, but it cannot simply announce:
“Trust me, somebody paid.”
Settlement comes back from infrastructure controlled by Boriable.
Exact amounts instead of unique wallets
For the current 1.0 architecture, Boriable can operate with static merchant receiving addresses.
Individual payments are distinguished using tiny adjustments at the atomic-unit level.
Instead of merely requesting:
0.293600 TRX
a particular order might request:
0.293621 TRX
That exact amount becomes part of the payment identity.
The same principle applies where appropriate across supported assets.
Boriable additionally protects against collisions through active-quote uniqueness on both sides of the architecture.
It means merchants don't have to hand Boriable private keys merely to generate addresses.
Then came the chains
Supporting “crypto” is wonderfully misleading terminology.
Bitcoin is not Ethereum.
Ethereum is not TRON.
TRON is not Solana.
And ERC-20 token transfers aren't native EVM transfers.
Eventually Boriable 1.0 supported:
Native coins: TRX, ETH, BNB, POL, SOL, LTC, XRP and BTC.
Stablecoins: USDC on Ethereum and Polygon, plus USDT on Ethereum and TRON.
Each has its own discovery peculiarities.
Solana taught us about unreliable public RPC endpoints.
Bitcoin taught us that a ten-cent test transaction isn't necessarily a particularly sensible Bitcoin transaction.
ERC-20 taught us considerably more.
“Ten at a Time” and “Ten Block Nailer”
Alchemy's free Ethereum-compatible RPC limits eth_getLogs queries to small block ranges.
Our first adaptive implementation tried increasingly smaller ranges.
100 blocks.
Nope.
50.
Nope.
25.
Nope.
12.
Still nope.
10.
Yes.
Technically adaptive. Practically ridiculous.
Hence “Ten at a Time.”
The next problem was older pending payments. Estimating the correct blockchain block from a timestamp wasn't accurate enough to guarantee that the transaction landed inside the range we were scanning.
The solution became “Ten Block Nailer.”
New ERC-20 payment registrations capture an actual blockchain block anchor. From there, monitoring advances deterministically in ten-block windows.
Legacy pending transactions can perform one bounded timestamp-to-block repair, establish a reliable anchor and continue forward from there.
That change autonomously recovered an old USDC Polygon payment we'd deliberately left hanging.
No manual transaction ID.
No diagnostic probe.
The Worker found it and FluentCart marked the order paid.
That was one of the moments when Boriable stopped feeling experimental.
“Keeping Tabs”
Once the engine worked, we needed to see what the hell it was doing.
The Keeping Tabs releases produced Boriable's diagnostics system:
Then came “Keeping Tabs: No Reloads”, because watching an administration page reload every time you changed a history filter felt rather 2004.
The transaction history became AJAX-driven.
Quote expiry is not payment expiry
This turned out to be an important distinction.
A crypto price quote might be locked for ten minutes.
That does not necessarily mean a payment arriving after 10 minutes should suddenly cease to exist.
Boriable therefore separates:
Quote lock — how long the displayed exchange rate remains current.
from:
Monitoring window — how long that exact payment remains watched.
A late exact payment can consequently still be detected and handled correctly rather than disappearing into the blockchain equivalent of the sofa cushions.
Then FluentCart asked the question that changed the product
During the integration discussion, FluentCart asked about the SaaS part.
More specifically: blockchain verification should happen on centralized infrastructure controlled by us rather than inside the distributed WordPress repository.
At which point we realized:
We had already built it.
The Cloudflare Worker wasn't merely a monitor anymore. It was Boriable's service boundary.
That led directly to licensing.
“Licence to Verify”
FluentCart's Software Licensing system issues the Boriable licence.
The WordPress plugin activates it.
But critically, the licence isn't merely a cosmetic WordPress unlock.
It becomes the SaaS entitlement/API identity.
When a new payment watch is registered, the verifier independently determines whether that installation is entitled to use the service.
That makes patching the PHP plugin largely pointless as a licensing bypass.
You could modify your local copy to display every crypto button in existence.
The Boriable verifier can still say:
No.
And because licensing must never interfere with money already in flight, an expired or invalid entitlement prevents new payment registrations but does not abandon existing watches.
Once Boriable has accepted responsibility for watching a payment, it finishes the job.
Free versus The Full Beast™
That architecture made a genuinely useful Free edition possible.
Boriable Free
TRX only.
10 confirmed crypto transactions per UTC calendar month.
Boriable Pro
The complete supported asset set.
No Boriable transaction limit.
Both use the same plugin and the same verifier.
The server determines entitlement.
During testing, our Free licence successfully:
We then made another TRX payment using Free to purchase Boriable Pro.
Thus Boriable Free successfully sold its own upgrade.
We hadn't planned that test.
We rather liked it.
The Pro licence was activated and checkout immediately expanded into what had by then inevitably become known as:
The Full Beast™.
“Schrödinger's Switch”
Licensing also produced one particularly entertaining bug.
FluentCart said the gateway was disabled.
Inside the gateway settings, its switch said enabled.
Both observations were technically correct because we'd accidentally conflated:
gateway enabled
with:
gateway licensed.
Schrödinger's payment gateway was simultaneously alive and dead depending on which UI you looked at.
We separated those states.
Then licensing activation produced another mystery: FluentCart's API was apparently returning invalid JSON.
We instrumented the response.
HTTP 200.
Content-Type: text/html.
153 KB.
Beginning with the homepage of helmar.live.
Our licensing authority had accidentally become the wrong WordPress site.
Schrödinger's cat did not survive the investigation.
The diagnostic did.
“Moving House”
Boriable also acquired portable settings.
Wallet addresses, enabled assets, infrastructure settings and pricing configuration can be exported into a versioned JSON document and imported into another installation with a preview before anything is applied.
Licence identity and transaction history deliberately stay behind.
Infrastructure authority also stays under Boriable's control rather than being transported as merchant configuration.
Hence:
Moving House.
Take the furniture.
Don't take the electricity company.
The negative progress bar
Even the little “Monitoring the blockchain…” panel became an engineering discussion.
Initially it had an animated border.
It looked nice.
Barely.
Then we asked the more useful question:
If we're animating something, why shouldn't the animation communicate information?
Boriable 1.0 therefore uses a draining background to represent the time until the next status poll.
And polling itself is adaptive.
Fast chains are checked by the customer interface more frequently. Bitcoin gets a more leisurely rhythm. Once a transaction has actually been detected, the interface accelerates because that's the moment when the customer cares most about seeing confirmation.
The animation isn't just decoration anymore.
It means something.
Why “Boriable”?
Somewhere during development the name appeared.
It isn't a blockchain term.
It isn't a tortured acronym.
The meaning gradually became obvious:
Boring + Reliable.
Crypto can be volatile, complicated and exciting.
Payment infrastructure shouldn't be.
The ideal Boriable transaction is profoundly uneventful:
Customer pays.
Merchant receives.
Order becomes paid.
Nobody thinks about Boriable.
That may be the highest compliment payment software can receive.
Boriable 1.0 — Boringly reliable crypto payments.