💡 SNAP/EBT Vendor-Side Mobile Acceptance Integration

[github-actions[bot]]

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 in internal/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

Dimension	Score	Rationale
Feasibility	med	Depends on FNA API availability timeline; phased approach (deep-link → native) mitigates risk
Impact	high	Directly increases vendor revenue and market accessibility for SNAP recipients
Urgency	high	FNA cooperative agreement is open now; SNAP benefit cuts already in effect in 6 states

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.