Repository navigation
💡 SNAP/EBT Vendor-Side Mobile Acceptance Integration #429
Replies: 1 comment
Weekly UpdateWhat ChangedMajor USDA funding developments for SNAP mobile payments at farmers markets:
Competitive context: No competitor (Localize, Farmish, Seen Markets) surfaces SNAP acceptance as a discovery filter. MarketWurks and VibePro manage vendor admin but don't address customer SNAP discovery. Updated Assessment
RecommendationAdvance with refined scope — Markets should NOT process SNAP payments (respecting NFR14). Instead, focus on three layers:
This positions Markets as the discovery/coordination layer while the USDA grant ecosystem provides the payment processing infrastructure. |
Uh oh!
There was an error while loading. Please reload this page.
Summary
Enable vendors to accept SNAP/EBT payments directly on their smartphones within the Markets app, leveraging the FNA's new $4M cooperative agreement program for zero-cost mobile EBT processing. This goes beyond the existing SNAP badge idea (#69) by integrating actual payment acceptance into the vendor check-in workflow, reducing tool fragmentation for vendors who currently juggle separate payment terminals.
Market Signal
FNA (formerly FNS, renamed June 1, 2026) announced up to $4M over three years for cooperative agreements to develop a SNAP Mobile Transaction Processing Application that lets direct-marketing farmers accept EBT on their own smartphones at no cost. Under 20% of farmers market payments are now cash, with 250K+ monthly EBT transactions at markets nationwide. SNAP benefit cuts in 6 states (WV, FL, CO, LA, OK, TX) threaten market revenue, making frictionless acceptance critical for vendor survival. Sources: FNA Mobile Payment Pilot, Grants.gov FY2026 SNAP Mobile.
User Signal
Existing idea #69 proposes a manager-verified SNAP/EBT acceptance badge — a discovery feature. But vendors need the actual processing capability, not just a badge. The PRD's exception-first vendor UX and <10-second action SLO align perfectly with one-tap payment acceptance. Brad (vendor persona) already checks in via the app; adding payment processing to the same workflow reduces tool fragmentation. No feature requests or bug reports currently reference payment processing, indicating this is a latent need the market hasn't articulated yet.
Technical Opportunity
The planned architecture uses Firebase Auth + Go backend on Cloud Run with GraphQL. A payment processing integration would fit cleanly as a new GraphQL domain schema (
payment.graphqls) with resolvers ininternal/graph/. The MMKV offline queue already planned for check-in retry could handle payment transaction queuing for intermittent connectivity at outdoor markets. NFC tap-to-pay on smartphones (no dedicated hardware needed) is now standard across Square, Shopify POS, and the FNA's own pilot app. The port/adapter pattern in the Go backend allows swapping payment providers without touching resolver logic.Assessment
Adversarial Review
Strongest objection: Payment processing is a regulatory minefield — PCI compliance, state-by-state EBT rules, and FNA authorization requirements could add 6+ months of compliance work. Markets is a coordination platform, not a fintech app. Scope creep risk is severe.
Rebuttal: The FNA's cooperative agreement explicitly funds third-party apps to integrate their Mobile Transaction Processing API — the compliance burden is on the FNA's backend, not on Markets. Markets would integrate as a frontend, similar to how apps integrate Stripe. Implementation can be phased: Phase 1 = SNAP badge (existing idea #69), Phase 2 = deep-link to FNA-approved payment app, Phase 3 = native integration when API is available. Each phase delivers standalone value.
Suggested Next Step
Monitor FNA cooperative agreement timeline for API availability; design integration architecture as a payment port/adapter pattern that can initially deep-link to approved apps and later integrate natively. Coordinate with idea #69 (SNAP badge) as Phase 1.
All reactions