Illustrative example · Bicycle shop
How a bicycle shop could accept crypto across sales and repairs
An illustrative walk-through of a shop that mixes small repair tickets with larger bike sales, where one setup has to handle both comfortably.
This is a composed educational scenario built to show how the pieces fit for this kind of business. It does not describe a real CryptoLic customer, and it promises no particular result. Any figures are illustrative. We do this instead of testimonials so nothing here can be mistaken for a real endorsement.
Picture a bicycle shop that sells bikes and accessories and also runs a repair bench. A tube change is a few dollars; a new bike is four figures. One payment setup has to feel right across that whole range.
This example follows how such a shop might add crypto for both. Figures are illustrative and used to show the decision, not to predict a result for a real shop.
At a glance
| Business | Bicycle shop with retail and repair |
|---|---|
| Typical ticket | $8 repair to $2,000 bike (illustrative) |
| Current methods | Cards and cash |
| Goal | One setup that suits both small repairs and big sales |
| Equipment added | None beyond the counter tablet |
How they take payment today
Cards and cash at one counter for both the shop floor and the repair bench. Card fees pinch on small repair tickets and add up on big bike sales, just in different ways.
The pain points that started the question
- Fixed card fees that hurt on small repair charges.
- Percentage fees that add up on four-figure bike sales.
- A wish for one option that handles the whole range.
Why crypto came up
Lightning covers the small repair tickets cheaply and fast, while on-chain handles the occasional big bike sale with a fee that is trivial relative to the amount. Modern tools support both automatically, so one setup does the job.
The initial concerns
- "One setup for both?" Yes, tools pick Lightning or on-chain by amount.
- "Do we hold Bitcoin?" No. Auto-conversion to dollars.
- "Big-sale risk?" Receiving is safe; the shop settles to dollars anyway.
How they researched it
The owner read the Lightning-versus-on-chain comparison to confirm one tool covers both ranges, ran the fee calculator for the card baseline, and checked the POS Compatibility Center for register fit.
The decisions they landed on
- Method: both rails, Lightning for repairs and on-chain for bikes, chosen automatically.
- Custody: a processor with dollar settlement.
- Checkout: a dynamic QR on the counter tablet.
- Staff: one three-step routine for every ticket size.
The implementation, step by step
- Chose a processor supporting both rails with dollar settlement.
- Set up a dynamic QR on the counter tablet.
- Briefed staff on one routine for repairs and sales alike.
- Tested a small and a large transaction before going live.
Equipment and costs
No new hardware. The cost was the conversion fee, weighed against card fees across the ticket range. Illustrative and service-dependent.
Lessons worth keeping
- One setup genuinely covered both small repairs and big sales.
- Letting the tool pick the rail removed any per-sale decision.
- Auto-conversion kept the books consistent across ticket sizes.
Common misconceptions and pitfalls
- Misconception: you must choose one rail. Tools handle both by amount.
- Pitfall: a static code for varied prices across such a wide range.
- Pitfall: skipping a large-transaction test before going live.
Recommended next steps for a similar shop
- Run the fee calculator for your card baseline.
- Read Lightning vs. on-chain to confirm one tool covers both.
- Check register fit in the POS Compatibility Center.
- Pick a both-rails processor with dollar settlement.
The CryptoLic resources used in this example
- Credit Card Fee Calculator
- Lightning vs. on-chain Bitcoin
- POS Compatibility Center
- Payment Solutions Center
Every business lands somewhere a little different. The readiness quiz reads your situation and hands you an ordered plan, then the resources above fill in the detail.
More examples