SPIKE: how do vendors accept payments in Gambit's current state? (deeplink/QR vs Tap to Pay entitlement vs Terminal) #705
Assignees
gambit-admin
Clear assignees
gambit-admin
No Assignees
Notifications
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: gambit/gambit#705
Reference in New Issue
Block a user
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
Child of #702. Decide how a vendor physically takes a payment into their own connected account, given Gambit is an Expo mobile + Next.js web app and we do NOT yet hold Apple's Tap to Pay entitlement.
Options to evaluate
application_fee_amount); the app shows a QR / deeplink the buyer scans and pays on their own phone. Works TODAY — no Apple entitlement, no hardware. CNP pricing. This is the "maybe deeplinks?" path — likely the fastest near-term win.com.apple.developer.proximity-reader.payment.acceptance— the blocker Kris named. Best in-person UX + CP rates, but needs a native module, an EAS build, and Apple approval (weeks). Action: file the entitlement request in parallel and track it.Deliverable: a short recommendation + a thin prototype of the leading option. Seed recommendation: ship option 1 (QR/deeplink Checkout on the connected account) now for immediate acceptance, and pursue the Apple entitlement for option 2 in parallel. Fee note: option 1 is CNP-priced; weigh against CP for high-ticket in-person sales.
Filed from a Claude Code session
Resolved during scoping for #703: went with Checkout Session redirect on the vendor's own device (buyer completes payment in an in-app browser, Stripe redirects back into Gambit) as the primary path — no Apple Tap-to-Pay entitlement, no native module, no EAS build needed. A Stripe Terminal PaymentIntent + ConnectionToken path was also built for a vendor with a paired Bluetooth reader, as the card-present alternative. Both ship in PR #472 (Gambit-Inc/gambit#472). QR-to-a-second-device and native on-device Tap to Pay are both out of scope now — closing this out.