Merchants needed more than a checkout link.
F18 Pay had to handle stores, invoices, request links, wallet access, and brand controls without forcing merchants to stitch together separate tools.
A merchant payment layer for Bitcoin and Ethereum stores that need invoices, payment requests, branded checkout surfaces, wallet controls, and clearer operational state in one place.
Separate Bitcoin and Ethereum flows keep configuration and support simple.
Public invoice pages show the amount due, QR address, and current status.
Sensitive wallet actions sit behind verification instead of an open download.
Flat18 treated F18 Pay as a controls and trust problem. The product had to help merchants create stores, manage brand and wallet state, issue invoices, create payment requests, and support payments without hiding the parts that usually go wrong.
F18 Pay had to handle stores, invoices, request links, wallet access, and brand controls without forcing merchants to stitch together separate tools.
Each store carries its own identity, currency mode, and operational settings. That keeps Bitcoin and Ethereum workflows separate and easier to support.
Wallet access sits behind verification, invoice states stay clear, and payment requests carry enough context to support a real transaction later.
F18 Pay is not just a QR checkout. It is an operating layer for stores, invoices, requests, wallet access, and payment entry points.
Buttons and payment pages can be generated in the same brand system, so merchants can embed a payment experience instead of a generic link.
Invoice tables show due amounts, statuses, and date ranges so support teams can answer questions quickly.
Request links, recipient emails, and status fields keep follow-up clear after a request leaves the dashboard.
Store identity, wallet access, invoices, payment assets, and request flows stay visible in one place, which makes the whole payment system easier to operate and support.
Flat18 treated F18 Pay as a controls and trust problem. The product had to help merchants set up stores, issue invoices, manage wallet access, and present a public payment flow without hiding the important state.
Merchants needed stores, invoices, requests, wallets, and public payment pages in one system, not a pile of disconnected tools.
The store had to be the centre of the product. If the merchant could not see state, the support load would only move elsewhere.
We built store setup, payment assets, invoice tracking, request flows, wallet verification, and public payment states into one operating layer.
Merchants can support real payments with clearer status, fewer hand-offs, and less guesswork when something needs checking.
Flat18 can turn merchant operations into a clear product with the right screens, state, and support flow.
Share the goal, deadline and current state. We will reply with the best route and next step.