The Problem: Payment Hardware is Expensive
A fintech startup approached us with a vision: eliminate payment hardware entirely for mobile businesses.
The pain point for field service teams:
- Hardware readers: $100 each × 20 employees = $2,000 upfront
- Annual replacements: $300/year (15% failure rate)
- Lost/forgotten devices = 5-10 lost sales weekly
- Support burden: 30% of tickets are "reader not working"
Real scenario: Home service technicians need to accept payments on-site. With hardware:
- "My reader died" = lost sale
- "I forgot my reader" = delayed payment
- Result: Only 40% acceptance rate
The Solution: NFC-Enabled Phones as Payment Terminals
The vision: use the NFC chip already in smartphones (the same tech powering Apple Pay) to accept payments instead of just making them.
How it works:
- Merchant enters amount: "$45.00"
- Customer taps contactless card on merchant's phone
- Payment processes in 1-2 seconds
- Funds settle to merchant's account
Accepts: Contactless cards (Visa, Mastercard, Amex) and digital wallets (Apple Pay, Google Pay).
Technical Challenges We Helped Solve
1. Native Integration for NFC Access
Challenge: Flutter can't directly access NFC chips for payment processing—manufacturers restrict this for security.
Our solution: Built platform bridges connecting Flutter UI to native payment SDKs (Stripe Terminal). Kotlin (Android) and Swift (iOS) handle secure NFC communication.
2. Security Without Seeing Card Data
Challenge: Payment data is sensitive. Compliance requirements are strict.
Implementation:
- Card data encrypted at NFC chip (never plaintext)
- Stripe SDK handles all card numbers (we only see tokens)
- Location verification prevents fraud
- PCI DSS compliant by design
3. Device Fragmentation
Android challenge: NFC quality varies wildly. Flagship phones (Pixel, Galaxy) work perfectly. Budget phones (under $200) have weak NFC.
iOS challenge: Only iPhone XS+ supports tap-to-pay (iOS 15.4+).
Solution: Device compatibility checks on launch, with clear upgrade recommendations for unsupported devices.
Results After Launch
Before (hardware readers):
- Setup: 2-3 days
- Cost: $2,000 + $300/year
- Acceptance: 40%
- Support: 30% tickets payment-related
After (phone-only):
- Setup: 5 minutes
- Cost: $0
- Acceptance: 92%
- Support: Under 5% tickets
Transaction metrics:
- 98.2% success rate
- 3-5 second processing time
- 450 transactions/day at peak
- $2,800 largest transaction (Apple Pay)
Year one value:
- Hardware saved: $2,300
- Labor savings: $9,000 (fewer support tickets)
- Revenue increase: $15,000 (92% vs 40% acceptance)
Key Lessons
1. Hardware elimination changes behavior
Expected: Save $2,000 on readers. Reality: Employees accept cards 2.3× more often.
Why? No "my reader isn't charged" excuses. Everyone has their phone.
2. Permission requests need context
Location services are required (fraud prevention). Without explanation, 40% denied permission. With clear context ("verify you're at your registered business"), denial dropped to 5%.
3. Offline won't work (plan fallback)
Tap-to-pay requires internet. For poor connectivity areas, manual card entry provides a fallback. 8% of transactions use it.
When This Makes Sense
Good fit:
- ✅ Mobile users (field services, delivery, events)
- ✅ Employees with smartphones
- ✅ Transactions under $500
- ✅ Hardware cost is a barrier
Poor fit:
- ❌ High-volume retail (need faster throughput)
- ❌ Stationary businesses (hardware not burdensome)
- ❌ Regularly over $1,000 transactions
ROI threshold: 10+ terminals needed? Savings pay back in month one.
Built with: Flutter (cross-platform), Stripe Terminal SDK (payment processing), Firebase (backend). Stripe handles compliance, fraud detection, and multi-country support.
Building a fintech product or mobile payment solution? Let's talk →
We help startups build payment systems that reduce friction and eliminate unnecessary hardware.