---
name: migrate-from-stripe-connect
description: Move a marketplace or platform from Stripe Connect to Fynex, or compare the two. Use when the user mentions Stripe Connect, connected accounts, destination charges, application_fee_amount, transfer_data, separate charges and transfers, Accounts v2, or asks for a Stripe Connect alternative or how to migrate a platform off Stripe. Maps each Connect concept to its Fynex equivalent, names the three that have no equivalent, and says plainly when staying on Connect is the right call.
---

# Migrating from Stripe Connect

The models are close enough that most of a Connect integration transfers, and different
in one place that decides the whole port: **on Fynex the split is declared on the payment
that collects the money.** There is no transfer call afterwards.

## Concept map

| Stripe Connect | Fynex |
|---|---|
| Connected account | **Payee** — `POST /payments-api/v1/payees` |
| Account onboarding / KYB | Dashboard onboarding, or `POST /payments-api/v1/payees/setup` for payee + payout method + wallet in one call |
| `transfer_data[destination]` on a PaymentIntent | An entry in `orderData.payeeDistribution` on `POST /payments-api/v1/checkout` or `/initialize-payment` |
| `application_fee_amount` / `transfer_data[amount]` | **Nothing.** Whatever you do not distribute stays with you — that is the fee. You never add a line for yourself |
| Separate charges and transfers (Transfers API) | **No equivalent.** Declare the distribution on the payment; you cannot move funds after the fact |
| `refunds` with `reverse_transfer=true` | Just refund. The split unwinds per party's share automatically — there is no flag |
| `refund_application_fee=true` | Implied by the same rule |
| Connected account balance | **Wallet**, per currency — `GET /payments-api/v1/wallets` |
| Automatic payout schedule | Explicit `POST /payments-api/v1/payouts`. Fynex does not pay out on a schedule; you decide when |
| `on_behalf_of` / settlement merchant | No equivalent axis |
| Accounts v2 `dashboard` / `fees_collector` / `losses_collector` | No equivalent axes. The platform collects fees and carries losses |
| Webhook events | One signed pipe for Payments and Billing. `X-Fynex-Signature: sha256=…` over the raw body, plus `X-Fynex-Timestamp`. Deduplicate on `eventId` |

## The three that will actually cost you time

1. **Deferred transfers.** Any flow that charges first and decides the split later has to be
   restructured so the distribution is known at charge time.
2. **Amount units.** Stripe is minor units everywhere. Fynex checkout takes MAJOR units
   (`49.99`) while payouts take minor (`4999`). Read the field name; neither rejects the
   wrong one, so a straight port is silently wrong by a factor of a hundred.
3. **Payout timing.** If you relied on Stripe's schedule, you now own it — and you must
   check `withdrawableBalanceMinor`, not `availableBalanceMinor`, before creating one.

## Stay on Connect if

- You need deferred or retroactive transfers, or to move funds between accounts after a charge.
- Your sellers need their own full payments dashboard and their own Stripe relationship.
- You depend on Stripe-hosted seller onboarding UI, embedded components, or Stripe carrying
  loss liability on negative balances.
- You are already live, the integration works, and nothing above is a problem you have.

Fynex is the better fit when the split itself is the product: marketplace commission on
every transaction, many payees per payment, EU VAT literacy on both the buyer invoice and
the commission, and payouts and billing reconciled against each other rather than in two
systems.

## Read next

- [Splits](/payments-api/v2/docs/splits.md) · [Payees](/payments-api/v2/docs/payees.md) · [Payouts](/payments-api/v2/docs/payouts.md)
- [Getting started](/payments-api/v2/docs/getting-started.md) · [/keys](/keys)
- [Agent index](/payments-api/v2/llms.txt) · [Both APIs](/api-reference)