The transfer API call is easy. The testing setup is not.
Stripe Connect lets platforms move money to connected accounts.
The API is four calls:
- Create a transfer to a connected account
- Verify the transfer.created webhook fires
- Create a payout from the connected account
- Verify the payout.created webhook fires
On paper, that is maybe ten minutes of reading.
In practice, getting to the point where you can actually test this flow takes much longer than the code itself.
The setup tax
Before you can make a single test transfer, you need:
- A platform account with Connect enabled
- A connected account that has completed onboarding
- That connected account needs a verified external account (bank details) for payouts
- Your platform needs the right capabilities configured
- Enough test balance in the right currency
That is a lot of infrastructure for what is ultimately four API calls.
Most developers skip the full setup. They test the transfer call in isolation, hardcode a connected account ID, and hope the payout works the same way in production.
That is not really testing the integration. That is testing one endpoint with a hardcoded parameter.
The part people skip
The webhook verification is the part that matters most and gets tested least.
In production, transfer.created is how your system knows funds actually moved. If your webhook handler is not processing that event correctly, your app might show a successful transfer to the user while the money is still sitting in your platform account.
Same for payout.created. Your connected account's dashboard should reflect the payout, but if the webhook never fires or your handler drops it, the seller thinks they got paid and you have a support ticket in 48 hours.
Testing this against real Stripe means:
- Setting up a webhook endpoint reachable from the internet
- Waiting for Stripe to deliver the event
- Parsing the event and verifying the payload contains the right transfer ID
- Making sure your handler is idempotent in case Stripe retries
Most teams punt on this and test it manually in staging. Once. And then never again.
What the flow actually looks like
POST /v1/transfers
→ 200: { id: "tr_1abc...", amount: 5000, currency: "usd" }
→ webhook: transfer.created fires with transfer ID
GET /v1/transfers/tr_1abc...
→ 200: { status: "paid" }
POST /v1/payouts
→ 200: { id: "po_2def...", amount: 5000 }
→ webhook: payout.created fires with payout ID
GET /v1/payouts/po_2def...
→ 200: { status: "paid" }
Four calls. Two webhooks. Each step depends on IDs and state from the previous one.
The transfer ID from step 1 is what your system uses to track the money. The payout in step 3 only makes sense if the transfer actually landed. The webhooks in between are what your production system will rely on to update its own state.
If you only test each endpoint individually, you are testing four unrelated API calls. You are not testing a transfer-to-payout flow.
The gap between endpoint and flow
This is the same pattern that shows up across almost every multi-step API integration.
Each endpoint works fine on its own. The docs explain each one clearly. But the docs do not usually explain:
- What order to call them in
- Which IDs carry from one step to the next
- Which webhooks fire between steps
- What happens if you skip a step or call them out of order
That gap is where the debugging time lives.
Not in the API call itself. In the space between calls.
Running the whole thing without the setup
I wanted a way to test this flow without setting up a connected account, without configuring capabilities, and without waiting for webhook delivery.
So I built a sandbox where you paste the curl and the state persists between calls. The transfer creates a real resource in the sandbox. The webhook fires automatically. The payout references the actual transfer. The IDs chain through every step.
No Stripe API key. No connected account. No webhook endpoint to host.
You verify the workflow, not just individual endpoints.
Try the Stripe Connect workflow
The honest version
I do not think this replaces Stripe test mode. If you are testing real card capture, real checkout flows, or anything that touches Stripe's actual infrastructure, you should use test mode.
But if you are trying to answer a simpler question — "does my transfer-to-payout flow work end to end, including the webhooks?" — you should not need 30 minutes of setup to find out.
That is the part I am trying to fix with FetchSandbox.
Curious how other teams handle Connect testing. Do you maintain a permanent test connected account, set up a fresh one for each project, or just skip the webhook verification and hope for the best?
Top comments (0)