Splice API

Landing Page
Documentation
Demo Page

Inspiration

49% of non-users cite a lack of technical understanding as their primary barrier to entry to cryptocurrencies, while 30% specifically avoid the space due to the 'operational complexity' of managing wallets. We wanted to combine the Stripe Best Web API and Best Use of Solana tracks by tackling the fiat–crypto gap. Many Solana apps (e.g. web3 games, online casinos) assume users already have a wallet and understand crypto, which excludes a huge audience. We built Splice API so users can fund and cash out in USD only—no wallet setup, no seed phrases—while we handle Solana and USDC under the hood.

What it does

Splice API is a Web API that lets non–crypto-native users interact with Solana-powered apps using only USD. Users pay with a card via Stripe Checkout, and we credit devnet USDC to a server-managed “burner” Solana wallet tied to their session. They play or use the app, and when they cash out, we move USDC back on-chain and pay them in USD via Stripe Connect (instant payouts or transfers to a connected account). From the user’s perspective it’s: pay in USD → use the app → get paid in USD. We expose a REST API so any frontend or game can plug in the same flow.

How we built it

We built a Fastify API that sits between Stripe and Solana. Backend stack: Fastify with @fastify/cors, @fastify/sensible, fastify-raw-body for webhook verification; Stripe for Checkout, webhooks, and Connect Express; @solana/web3.js and @solana/spl-token for burner wallets and USDC; Helius for Solana devnet RPC; @coral-xyz/anchor for our Solana program interface; Upstash Redis for player/game state and idempotency. We generate a keypair per player, encrypt it with AES-256-GCM, and store it in Upstash. When Stripe fires checkout.session.completed we transfer USDC from our treasury to the burner via Helius. On cashout we pull USDC back and trigger a Stripe payout or transfer. We use idempotency keys in Redis on join/move so duplicate requests don’t double-spend.

Challenges we ran into

Stripe Connect setup: Enabling Connect (negative balance liability, compliance) and getting test onboarding to complete reliably; we used a preconfigured Connect account for the demo so judges didn’t have to onboard.

Stripe Crypto Onramp: We wanted to use Stripe’s Crypto Onramp for card → USDC, but it required approval that would have taken too long for the hackathon, so we pivoted to our own Checkout → treasury → burner flow and used ngrok to expose localhost for webhook callbacks and testing.

Fiat–crypto bridge in test mode: There’s no automatic conversion of on-chain USDC to Stripe balance, so we simulate the payout step in demo mode so the full flow works without platform balance issues.

Accomplishments that we're proud of

Single API tying Stripe (Checkout, webhooks, Connect) and Solana (burner wallets, USDC via Helius, optional game state in Upstash) into one flow.

Security: Burner keys AES-256-GCM encrypted at rest in Upstash Redis; Stripe webhook signature verification; idempotency on join/move; no keys or seed phrases for the end user.

Demo-ready UX: Landing + demo (React/Vite) with create player → Stripe Checkout → balance refresh → cashout to a preconfigured account, with clear success/error states.

Documentation: README, Postman collection, and Fastify Swagger /docs all aligned with the live API.

What we learned

How to run Stripe Checkout and Connect together (onboarding, payouts/transfers) and how platform vs connected-account balance and capabilities affect the flow.

Designing server-held burner wallets with @solana/web3.js and @solana/spl-token (keypair generation, encryption, Upstash for state) and when to mark players inactive vs re-use.

Balancing hackathon demos (e.g. one shared Connect account, simulated payout) with a path to production (per-user Connect, real payouts).

What's next for Splice API

Production Stripe: Real Connect onboarding per user, real payouts, and (if needed) Stripe Crypto Onramp for true card → USDC where approved.

Full game loop: Wire our Anchor program end-to-end (escrow, on-chain moves, winner payout) so the demo reflects a real game round.

Compliance and scale: KYC/limits if we hold user funds longer; consider moving long-term state to a database with auth while keeping Upstash for hot path and idempotency.