Stripe engineering guide: Stripe Connect International: Cross-Border Payouts, Currencies and Platform Fees Explained

Stripe Connect international setups work when the platform and the connected account are in a supported pairing. Platforms in the US, UK, EEA, Canada or Switzerland can transfer funds to connected accounts in any of those regions using destination charges or separate charges and transfers without `on_behalf_of`. Outside those regions, the platform and seller generally need to be in the same region, unless the seller is made the settlement merchant with `on_behalf_of`.

This guide is for teams building marketplaces and platforms whose sellers, providers or customers sit in more than one country. It covers how to check which countries your accounts can be in, how cross-border payouts work and where they stop, what `on_behalf_of` changes across borders, where currency conversion happens in each funds flow, which currency an `application_fee_amount` arrives in, the recipient service agreement, why peer-to-peer use cases are restricted, payout schedules and negative balances, and tax reporting. It ends with an architecture checklist. Charge-type basics are in our guide to direct vs destination charges, and the wider build in our Stripe integration guide. Everything here was checked against Stripe's documentation in October 2026; Stripe changes these rules, so confirm your own pairing.

01Which countries can Stripe Connect platforms and connected accounts be in?

Short answer: it depends on three separate lists, and you need to check each one for your exact countries rather than assume. The platform's own country must be one where Stripe is available, each connected account's country must be supported for the capabilities you request, and the pairing between them must be supported for the funds flow you choose.

A seller can be in a country where Stripe accepts payments yet still be unreachable from your platform with the charge type you picked, because cross-region support is defined per funds flow. We do not reprint country lists here; they change, and a stale list is worse than none. Here is how to check each layer.

1. Platform country. Your platform account's country decides your default settlement currency, your fee structure and which cross-border rules apply to you. It is set when the account is created and is not something you change casually.
2. Connected account country and capabilities. Each country has its own required verification information and its own set of available capabilities. Stripe's required verification information page is also where it tells you which countries support the recipient service agreement. Payment method capabilities have their own supported business locations, listed per method in Stripe's account capabilities documentation.
3. The pairing and the funds flow. Whether money can move from your platform's balance to a seller in another country depends on the regions involved and on whether you use `on_behalf_of`. This is the layer most often missed, and it is the subject of the next three sections.

Two practical habits help. First, complete your platform profile in the Stripe Dashboard; Stripe uses it to recommend charge types and capabilities for your business model. Second, prove each new country in a sandbox before sales promises it: create a test connected account in that country with the exact capabilities and service agreement you intend to use, run the full charge, transfer and payout path, and record the result. Note that Stripe's own documentation warns that sandboxes might not enforce some capabilities, so treat a sandbox pass as necessary but not sufficient, and confirm unusual pairings with Stripe directly.

02How do Stripe Connect cross-border payouts work?

Cross-border payouts let a platform transfer funds to connected accounts in other countries, in their local currencies. Stripe documents self-serve support for platforms based in the US, UK, EEA, Canada or Switzerland transferring to connected accounts in any of those regions, regardless of the payment settlement currency.

Stripe's cross-border payouts documentation gives two examples that make the shape clear: a platform in the UK can pay out to a seller in the US, and a platform in Germany can pay out to a seller in Canada. The mechanism underneath is a cross-border transfer on the payments balance, followed by the seller's ordinary payout to their local bank. Stripe states the same rule from the transfer side: cross-border transfers are supported between the United States, Canada, the United Kingdom, the EEA and Switzerland, and in other scenarios the platform and the connected account must be in the same region. Attempting to transfer across unsupported borders returns an error.

The limits matter as much as the availability. As of October 2026, Stripe lists these constraints for cross-border payouts:

• Only some funds flows qualify. Separate charges and transfers without `on_behalf_of`, top-ups and transfers, and destination charges without `on_behalf_of`. Direct charges are not on that list, because a direct charge already settles in the connected account's own country.
• No cross-border payouts to recipient accounts. Connected accounts on the recipient service agreement cannot receive cross-border payouts. Stripe points those platforms to Global Payouts instead, a separate product with its own country coverage.
• Nothing self-serve outside the listed regions. For countries outside the US, UK, EEA, Canada and Switzerland group, Stripe asks platforms to contact sales or consider Global Payouts.
• Fees depend on the recipient's location. Stripe prices cross-border payouts by where the recipient is. We do not quote figures; check Stripe's Connect pricing page and your own agreement.

A cross-border payout is a property of the whole path, not of the seller: the same UK seller can be reachable with a destination charge, unreachable as a recipient account, and reachable another way as the settlement merchant. The decision flow below summarizes the checks.

03What does on_behalf_of change when the seller is in another country?

Setting `on_behalf_of` makes the connected account the settlement merchant for an indirect charge: the charge settles in the seller's country and settlement currency, uses that country's fee structure and shows the seller's statement descriptor. Across borders, it is also the route Stripe names for pairings outside the supported cross-border regions.

Stripe's destination charges documentation is explicit about the cross-border case: with certain exceptions, if your platform and a connected account are not in the same region, you must specify the connected account as the settlement merchant using `on_behalf_of`. The exceptions are the cross-border transfer regions described above. Read the two rules together and the picture is consistent. Inside the US, UK, EEA, Canada and Switzerland group, you can keep the platform as the business of record and move funds across the border with a transfer. Outside it, the platform cannot be the settlement merchant for a seller in another region, so the charge has to settle where the seller is.

When `on_behalf_of` is set, Stripe documents these effects:

• Charges settle in the connected account's country and settlement currency.
• The fee structure for the connected account's country is used, and those country-specific fees are charged to your platform account.
• The connected account's statement descriptor appears on the customer's card statement.
• If the connected account is in a different country from the platform, its address and phone number appear on the customer's statement too.
• How long the pending balance is held before payout depends on the connected account's own `delay_days` setting.

What it does not change matters just as much. Refunds and disputes on destination charges and separate charges and transfers still debit the platform's balance, with or without `on_behalf_of`. And `on_behalf_of` is only supported for connected accounts with a payments capability such as `card_payments`, which accounts on the recipient service agreement cannot request. So the cross-region escape hatch is only open to sellers who were onboarded as full merchants, with the heavier verification that implies. If your onboarding flow requested only `transfers`, adding `card_payments` later reopens requirements for every affected seller; our Connect onboarding guide covers how to handle that without stranding them.

There is also a customer-experience cost: across borders, the customer sees a foreign business and address on their statement. Unrecognized names invite disputes, and on indirect charges the platform pays for them, so make the seller-platform relationship obvious on receipts.

04Where does currency conversion happen in Stripe Connect?

Currency conversion happens wherever money moves between balances or currencies that differ: at the charge when the presentment currency differs from the settlement currency, on a transfer when the platform's balance currency differs from the seller's, and at payout when there is no bank account for a balance's currency. Which of those points apply depends on the funds flow.

Stripe's multi-currency documentation for Connect defines the rule simply: FX takes place when the starting currency of a funds flow is different from the destination currency. When Stripe converts, it generally applies a mid-market rate sourced from third-party providers, and conversion is subject to fees on Stripe's pricing page. Stripe's FX Quotes documentation then walks through each funds flow. Summarized:

• Direct charges. The charge converts from the presentment currency to the connected account's default currency. The application fee converts to the platform's default currency.
• Destination charges without `on_behalf_of`. Two conversions are possible. The charge converts from presentment currency to the platform's settlement currency, and then the amount transferred converts to the connected account's settlement currency.
• Destination charges with `on_behalf_of`. The charge converts once, from presentment currency to the connected account's settlement currency. There is no second conversion on the transfer.
• Separate charges and transfers without `on_behalf_of`. The charge converts to the platform's default currency, and each later transfer converts again if the seller's default currency differs.
• Separate charges and transfers with `on_behalf_of`. The charge converts to the connected account's default currency, so the later transfer needs no conversion.
• Refunds. A refund of a converted payment uses the live rate at the time of the refund, even if you locked a rate for the original payment, and Stripe does not refund the FX fee charged on the original transaction.

If the connected account has enabled the presentment currency through multi-currency settlement, Stripe converts to that currency instead of the default. And the FX Quotes API, currently documented with a preview API version, lets you lock a rate for a charge or a transfer for a period, which helps when you quote prices in the customer's currency. Note the gap Stripe documents: for destination charges without `on_behalf_of`, you can quote the charge conversion but not the conversion on the transfer to the connected account, nor the conversion of application fees.

For finance teams, lane A means two rates on one order, applied at different moments. If seller terms promise “85% of the order value”, define in which currency and at which point that 85% is measured.

05How does application_fee_amount work in multi-currency payments?

`application_fee_amount` is always computed in the charge currency and capped at the charge amount, but the currency it lands in depends on the funds flow. On a cross-border destination charge, the platform receives the fee in the connected account's settlement currency, which may differ from the platform's own.

This is the detail that most often surprises a platform's finance team. Stripe's destination charges documentation lists the rules for `application_fee_amount`: it is capped at the total transaction amount, always computed in the same currency as the transaction, and settles in the same currency as the connected account's settlement currency, which for cross-border destination charges might differ from your platform's settlement currency. Mechanically, Stripe transfers the full charge amount to the destination account after capture and then transfers the application fee back to the platform; the FX documentation adds that Stripe deducts the fee after converting the transferred funds. The platform then pays the Stripe fee on the charge from its own balance.

The alternative, `transfer_data[amount]`, behaves differently. You pass the seller's share instead of your fee, and the amount you keep stays with the platform in the platform's settlement currency. The trade-off Stripe documents is visibility: with `transfer_data[amount]`, a connected account using a Stripe-hosted dashboard sees only the amount transferred, not the total charge, and there is no Application Fee object for reporting. With `on_behalf_of`, both mechanisms credit the platform in the connected account's settlement currency.

A worked example

Illustrative only. A US platform settles in USD. A seller in the UK settles in GBP. A customer in Ireland pays €100.00, and the platform takes a €10.00 fee, so the PaymentIntent has `amount: 10000`, `currency: "eur"` and `application_fee_amount: 1000`. Without `on_behalf_of`, Stripe converts the charge from EUR to the platform's USD, converts the transferred amount into the seller's GBP, and deducts the fee after converting, so the platform's €10.00 fee arrives in GBP. If the platform had used `transfer_data[amount]: 9000` instead, the €10.00 it retained would sit in USD. Same economics in the charge currency, two different currencies on the platform's balance.

Below is a minimal Node.js sketch that chooses between a plain destination charge and one with `on_behalf_of`, based on the seller's country, service agreement and capabilities, then creates the PaymentIntent with an application fee. The region lists live in configuration that you maintain from Stripe's documentation; they are not hard-coded facts. Amounts come from your own order and pricing logic on the server.

import Stripe from "stripe";
import { config } from "./config.js";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

// Maintained from Stripe's cross-border payouts docs; reviewed when Stripe changes them.
const crossBorder = new Set(config.stripeCrossBorderCountries);
const regionOf = (country) => config.stripeRegionByCountry[country] ?? country;

async function chooseFlow(platformCountry, sellerAccountId) {
  const seller = await stripe.accounts.retrieve(sellerAccountId);
  const transfersActive = seller.capabilities?.transfers === "active";
  const cardPaymentsActive = seller.capabilities?.card_payments === "active";
  const isRecipient = seller.tos_acceptance?.service_agreement === "recipient";

  if (!transfersActive) throw new Error("Seller cannot receive transfers yet");
  if (regionOf(seller.country) === regionOf(platformCountry)) return { onBehalfOf: false };
  if (crossBorder.has(seller.country) && crossBorder.has(platformCountry) && !isRecipient) {
    return { onBehalfOf: false }; // cross-border transfer, platform stays merchant
  }
  if (cardPaymentsActive) return { onBehalfOf: true }; // seller becomes settlement merchant
  throw new Error("Pairing not supported self-serve for this seller");
}

export async function createOrderPayment(order, seller) {
  const flow = await chooseFlow(config.platformCountry, seller.stripeAccountId);
  return stripe.paymentIntents.create(
    {
      amount: order.totalMinor, // in the presentment currency, from your order
      currency: order.currency, // e.g. "eur"
      automatic_payment_methods: { enabled: true },
      application_fee_amount: order.platformFeeMinor, // same currency as the charge
      transfer_data: { destination: seller.stripeAccountId },
      ...(flow.onBehalfOf ? { on_behalf_of: seller.stripeAccountId } : {}),
      metadata: { order_id: order.id, fx_shape: flow.onBehalfOf ? "obo" : "transfer" },
    },
    { idempotencyKey: "order_" + order.id + "_payment" }
  );
}

06How do separate charges and transfers work across regions?

Separate charges and transfers across regions follow the same cross-border transfer rules: supported between the US, Canada, UK, EEA and Switzerland, and otherwise only within one region unless the charge uses `on_behalf_of`. The extra care is in currencies, because each transfer is a separate movement that may convert again.

Stripe's separate charges and transfers documentation adds several details that bite in multi-currency marketplaces:

• Transfer currency must match when you use `source_transaction`. The currency of the balance transaction associated with the charge must match the currency of the transfer. For a EUR charge on a USD platform without `on_behalf_of`, that balance transaction is in USD, so the transfer is in USD and converts to the seller's currency on arrival.
• Transfers cannot exceed their source. With `source_transaction`, a transfer cannot exceed the charge, and several transfers against one charge cannot add up to more than it.
• Transfers without a source draw on available balance. They fail when the platform's available balance is short, and Stripe does not retry them. In a multi-currency platform, “available balance” is per currency, so a healthy USD balance does not fund a transfer you try to make from a GBP balance.
• Reversals can fail on conversion. If a transfer reversal requires a currency conversion and the reversal amount would result in a zero balance after conversion, Stripe returns an error. Reversals are also only possible when the seller's available balance covers them, unless connected reserves are enabled.
• Asynchronous payment methods need care. For bank debits, wait for `charge.succeeded` before transferring, because Stripe does not automatically reverse a transfer if the payment later fails.

The safest pattern for a multi-seller basket in several currencies is to compute each seller's share from the settled amount, in the settlement currency, rather than from the presentment amount. That is what the second sketch does.

import Stripe from "stripe";

const stripe = new Stripe(process.env.STRIPE_SECRET_KEY);

// Called once per order line after that seller fulfils it.
export async function paySellerShare(order, line) {
  const intent = await stripe.paymentIntents.retrieve(order.paymentIntentId, {
    expand: ["latest_charge.balance_transaction"],
  });
  const charge = intent.latest_charge;
  const settled = charge.balance_transaction; // amount and currency as settled on the platform

  // Shares are stored in basis points in your ledger, never computed in the browser.
  const amount = Math.floor((settled.amount * line.shareBasisPoints) / 10000);

  return stripe.transfers.create(
    {
      amount,
      currency: settled.currency, // must match the charge's balance transaction currency
      destination: line.sellerStripeAccountId,
      source_transaction: charge.id, // funds follow the charge's availability
      transfer_group: "order_" + order.id,
      metadata: { order_id: order.id, line_id: line.id, presentment: charge.currency },
    },
    { idempotencyKey: "transfer_line_" + line.id }
  );
}

Rounding down per line and keeping the remainder on the platform is a policy choice, not a Stripe rule; write it into your seller terms. The idempotency keys and the webhook handling that should sit around both sketches, where `transfer.created`, `charge.refunded` and dispute events can arrive more than once and out of order, are covered in our guide to Stripe webhooks best practices.

07What is the Stripe recipient service agreement, and when should you use it?

The recipient service agreement is an account setup in which Stripe has no direct service relationship with the seller; the seller's relationship is only with your platform. Recipient accounts can receive transfers but cannot process payments, cannot request `card_payments` and therefore cannot be the settlement merchant with `on_behalf_of`.

Stripe's service agreement types documentation describes two types, `full` and `recipient`, and notes that the content applies to platforms that are liable for negative balances and whose connected accounts do not have access to the full Stripe Dashboard. Under a `full` agreement, the seller has a service relationship with Stripe and can process card payments. Under `recipient`, the seller can only receive funds from the platform. You choose it with `tos_acceptance[service_agreement]` when creating the account through the API, or through the Transfers option in Connect configuration settings for accounts with Express Dashboard access.

The constraints are what make it an architectural decision rather than an onboarding setting:

• It is fixed once accepted. After a connected account accepts its service agreement, you cannot change the type. Changing it means creating a new account and re-onboarding the seller.
• It is not available everywhere. Stripe says the recipient agreement is available in select countries and points to its required verification information page for the list.
• Transfers take longer to become available. Stripe documents an additional 24 hours before transfers to recipient accounts become available in the connected account's balance.
• No self-serve cross-border payouts. As covered above, cross-border payouts do not support recipient accounts; Stripe routes those platforms to Global Payouts.
• Support runs through you. Stripe does not provide direct support to recipient accounts. The platform contacts Stripe on their behalf, which means your support team needs the tools and knowledge to do so.

It fits when sellers will only ever be paid by your platform and you are the business of record for every payment within one region. It does not fit when sellers may later need to be the settlement merchant, when you expect sellers in other regions, or when you may move to direct charges; the fixed choice would then cost a re-onboarding project.

08Can you use Stripe Connect for peer-to-peer payments?

Not for peer-to-peer money transmission. Stripe lists peer-to-peer money transmission among prohibited financial products and services, and prohibits processing where no bona fide good or service is sold or donation accepted. Connect is designed for platforms and marketplaces where a buyer pays for something a seller provides.

People search for “stripe peer to peer payments” for good reasons: splitting rent, sending money to a friend, paying back a group expense. Those flows move money between individuals without a sale, which is money transmission, and Stripe's restricted businesses list places it under prohibited businesses. The same list restricts money transmitters, remittances, currency exchange services and other money service businesses, and restricts crowdfunding platforms; restricted means those businesses need Stripe's prior approval or specific conditions, not that they can simply sign up. Some jurisdictions add their own lines; the list names, for example, C2C services outside Stripe Connect as prohibited in Japan.

The distinction that matters is not whether both parties are individuals. A marketplace where individuals sell handmade goods or tutoring sessions to other individuals is a normal Connect use case: the seller provides a good or service, the platform facilitates the sale, and the payment pays for it. What crosses the line is a product whose main purpose is to move funds from one person to another, especially across borders, where currency exchange and remittance rules apply as well.

If your product sits near that line, for example tipping, gifting, pooled group purchases or creator payouts funded by fans, describe the flow to Stripe before you build it, in writing, and get legal advice on whether it is money transmission where you and your users operate. We are not lawyers and this is not legal advice; it is the reason we ask about the purpose of every funds flow in our Connect reviews.

09How do payout schedules and negative balances work across countries?

By default, a connected account's funds are paid out on a daily rolling basis, but timing varies by country and account, and platforms can set schedules, send manual payouts or hold funds. A negative balance blocks payouts until it is positive again, and either Stripe or the platform is responsible for covering it, according to the account's configuration.

Payout schedules

Stripe's documentation on managing connected account payouts says platforms can schedule automatic payouts, send manual payouts, use instant payouts where available, and, with destination charges or separate charges and transfers, retain funds in the platform balance. Who can change a seller's schedule depends on dashboard access: for accounts without a Stripe-hosted dashboard, the platform manages payout accounts and schedules; for full Dashboard accounts, the platform needs platform controls. Settlement currencies are listed per country in Stripe's payouts documentation, and a balance in a currency without a matching bank account is converted to the account's default currency at payout. With `on_behalf_of`, the seller's `delay_days` decides how long the pending balance is held.

Sellers in different countries may see funds on different rhythms, because availability timing varies by country and payment method. Show expected payout dates from Stripe's data rather than one global promise, and drive payout status from `payout.paid` and `payout.failed` events. A failed payout disables the external account until it is updated.

Negative balances

Stripe's Connect account balances documentation sets out how negative balances work. Stripe offsets negative transactions against future payments where it can, and assigns refunds and chargebacks first to the account the charge was made on. Whether Stripe or the platform covers a connected account's negative balance is recorded on the account: `controller.losses.payments` on Accounts v1, or `defaults.responsibilities.losses_collector` on Accounts v2, with `application` meaning the platform. While the balance is negative, payouts to the seller's bank stop.

• Auto-debit works only in some countries. With `debit_negative_balances` enabled, Stripe can debit the seller's bank account. Stripe lists support for banks in Australia, Canada, SEPA countries including the UK, New Zealand and the United States, and notes it cannot correct a negative balance using a debit card.
• The platform holds a reserve. When the platform is responsible, Stripe holds a reserve on the platform's available balance to cover connected accounts' negative balances, released as those balances recover.
• After 180 days, the platform pays. If a connected account stays negative for 180 days, Stripe transfers funds from the platform's reserve to zero it out, as a Connect collection transfer.
• Holding funds has limits. Stripe advises against holding funds without a clear purpose and lists maximum holding periods that vary by the business's country.

Across borders, recovery gets harder. A reversal can be blocked by cross-border transfer restrictions, a seller's bank may not support auto-debit, and a reversal that needs currency conversion can fail. Stripe's own dispute guidance warns that cross-border transfer restrictions might prevent you from repaying a connected account after reversing a transfer. So for international sellers, decide recovery policy before launch: how long you hold funds, which payment methods you allow, and when an account with a persistent negative balance should be paused.

10Who is responsible for tax forms and reporting on a Connect platform?

Often the platform. Stripe issues US 1099-K forms only in specific configurations, and documents that for transactions where the platform controls pricing, the platform is responsible for filing any relevant 1099 forms. Other countries have their own reporting rules, which you need to check with a tax advisor.

Stripe's US tax reporting documentation for Connect explains the split. Stripe issues 1099-K forms for connected accounts where Stripe controls the pricing or where the connected account pays fees directly to Stripe. It does not issue them where `controller.fees.payer` is `application` or a related platform value; in those cases, the platform should consider which 1099 form applies, such as 1099-NEC, 1099-MISC or 1099-K. Stripe offers tax reporting tooling and the `tax_reporting_us_1099_k` and `tax_reporting_us_1099_misc` capabilities to collect information, and recommends consulting a tax advisor about your requirements. Thresholds and rules change; do not copy them from a blog post.

For an international platform, the engineering implications are concrete even where the legal answer is not yet known. Your account model should record each seller's tax residence and entity type separately from their Stripe country. Your data model should be able to total payments per seller, per calendar year, per currency. And your onboarding should be able to request additional tax information later without breaking a seller's ability to get paid. Platform reporting regimes outside the US exist in several jurisdictions; ask your advisor which apply to you before you onboard sellers there, not after.

11An architecture checklist for international Stripe Connect platforms

International Connect problems are rarely bugs in payment code. They are decisions about countries, agreements and currencies that nobody wrote down. Agree the answers below with whoever owns finance, support and compliance before the first international seller is onboarded.

From here, this article is about Cevrynt

12How Cevrynt approaches international Stripe Connect builds

Cevrynt, Inc. is a Stripe partner, and our Connect work starts with the country map and the funds flow rather than with code. Three of our engineers hold individual Stripe professional certifications: Arindam Pradhan, our founder (Implementation Architect), Anupam Pradhan (Payments Architect) and Subhadip Giri (Payments Architect). With our senior engineers, they check each platform and seller pairing against Stripe's cross-border rules, write down the settlement merchant, service agreement and currency for every flow, and then build the charge, transfer, refund, payout and webhook code, which you own at handover.

Every Connect project is scoped after a technical review, with a written scope before any work is billed. You can read how we work on our Stripe Connect service page, see the wider Stripe payments services overview, or tell us about your marketplace or platform. If you are still deciding on a charge model, start with our guide to direct vs destination charges.