# Transfer Mechanisms

Transfer mechanisms control **how** funds are moved to merchants at the payment provider level. While [Transfer Methods](/prism/payments/payment-settings/transfer-settings.md) (`AUTOMATIC`, `CUSTOM`, `EXTERNAL`, `DISABLED`) control **when** transfers occur, transfer mechanisms determine the underlying payment flow used to execute those transfers.

Violet supports two transfer mechanisms:

## Standard Transfers

Standard transfers use [Stripe's separate charges and transfers model](https://docs.stripe.com/connect/separate-charges-and-transfers), where payment capture and merchant transfers are distinct operations.

**How It Works:**

* Violet captures the payment from the shopper using your platform's Stripe account.
* Stripe deducts its processing fees and adds the remaining funds to your platform's available balance.
* A separate transfer operation is then initiated via Stripe's `/v1/transfers` API to move funds from your platform account to the merchant's connected account.
* The charge and transfer are decoupled, meaning you control the timing and amounts transferred independently.

**Key Characteristics:**

* **Flexible timing**: Transfers can occur immediately after capture, on a schedule, or triggered manually via API.
* **Independent operations**: The charge and transfer are separate API calls, allowing for custom logic between them.
* **Multi-recipient support**: A single charge can be split across multiple transfers to different connected accounts (useful for multi-merchant orders).
* **Merchant of record flexibility**: Either the platform or connected account can appear as the merchant of record using the `on_behalf_of` parameter.
* **Cross-border support**: Supports transfers between US, UK, EEA, Canada, and Switzerland (with 0.25% fee, waived within UK-EEA).

**Application / Use Case:**

* Suitable for most marketplace and platform use cases.
* Ideal when you need flexibility in transfer timing (immediate, batched, or custom).
* Works with all transfer methods (`AUTOMATIC`, `CUSTOM`, `EXTERNAL`).
* Best for platforms that need fine-grained control over when merchants receive funds.
* Required when a single order needs to be split across multiple merchants.

## Destination Payments

Destination payments use [Stripe's destination charge model](https://docs.stripe.com/connect/destination-charges), where payment capture and merchant transfer occur atomically in a single operation.

**How It Works:**

* Violet creates a Payment Intent with `transfer_data.destination`, specifying the merchant's connected account as the destination.
* When the payment is captured, the full charge amount is immediately transferred from the platform to the destination account.
* The `application_fee_amount` (your platform's commission) is then transferred back to the platform automatically.
* This is a single coordinated transaction—no separate transfer API call is needed.

**Key Characteristics:**

* **Atomic operation**: Payment capture and merchant transfer happen together—no separate transfer step required. This prevents timing mismatches between charging customers and paying merchants.
* **Platform as merchant of record**: By default, your platform name appears on customer statements, providing a consistent brand experience across all merchants. (Use `on_behalf_of` to change the settlement merchant if needed.)
* **Automatic Application Fee objects**: Stripe creates [Application Fee](https://docs.stripe.com/connect/application-fees) objects automatically, simplifying commission tracking and platform revenue reconciliation. These appear in Stripe's reporting tools.
* **Simplified fund flow**: Funds flow directly to the connected merchant account as part of the payment capture process—no need to manage transfer timing.
* **Cross-border considerations**: If your platform and a connected account aren't in the same region, you must specify the connected account as the settlement merchant using `on_behalf_of`.

**Application / Use Case:**

* Ideal for platform-centric marketplaces where the platform is the primary business entity customers interact with (similar to Airbnb or Lyft models).
* Useful when you want automatic, immediate payouts to connected accounts without managing separate transfer operations.
* Best suited for platforms that want explicit application fee tracking through Stripe's built-in reporting.
* Recommended when you need the guarantee that payment capture and merchant fund distribution happen together.
* **Note**: Destination charges work best for single-merchant transactions. For multi-merchant orders, standard transfers provide more flexibility.

{% hint style="warning" %}
**Important**: Destination payments currently require [Scheduled Transfers](/prism/payments/payment-settings/scheduled-transfers.md) to be enabled. This ensures proper coordination between payment capture and fund distribution timing.
{% endhint %}

{% hint style="success" %}
**Expanded Geographic Reach with Destination Payments**

When combined with [Scheduled Transfers](/prism/payments/payment-settings/scheduled-transfers.md), destination payments can support merchants in **more countries** than standard transfers alone.

**How it works**: With destination payments and scheduled transfers, Violet charges a saved payment method on your platform account and uses `transfer_data.destination` to move funds directly to the merchant's connected account. Because the charge originates from your platform account (not a cross-border transfer from your platform's balance), this bypasses some of the standard cross-border transfer restrictions.

**Result**: Merchants who onboard with a Stripe account in regions that wouldn't support standard Stripe transfers can still receive payouts through this mechanism. This is particularly valuable for platforms with a global merchant base.

**Requirements**:

* Scheduled Transfers must be enabled
* Platform must have a saved payment method configured (`destination_payment_method_id`)
* Merchant must have a valid Stripe connected account (Express or Standard)

Contact Violet to discuss whether destination payments can expand your supported merchant regions.
{% endhint %}

## Choosing the Right Transfer Mechanism

| Consideration               | Standard Transfers                               | Destination Payments                           |
| --------------------------- | ------------------------------------------------ | ---------------------------------------------- |
| **Default**                 | Yes                                              | No                                             |
| **Merchant of Record**      | Can be platform or connected account             | Platform is always merchant of record          |
| **Transfer Timing Control** | Full control (immediate, batched, or custom)     | Automatic upon capture                         |
| **Stripe Fee Tracking**     | Manual reconciliation                            | Automatic Application Fee objects              |
| **Operation Type**          | Separate charge and transfer                     | Atomic single operation                        |
| **Complexity**              | More flexible, slightly more complex             | Simpler, more automated                        |
| **Scheduled Transfers**     | Optional                                         | Required                                       |
| **Geographic Reach**        | Limited to Stripe's supported transfer countries | Expanded reach via platform-originated charges |
| **Multi-Merchant Orders**   | Supported (split across transfers)               | Single merchant per charge recommended         |

### When to Use Standard Transfers

Choose standard transfers when:

* You need maximum flexibility over transfer timing
* You want to implement custom conditions before transferring funds
* Your merchants should appear as the merchant of record on customer statements
* You're using `CUSTOM` or `EXTERNAL` transfer methods with manual control

### When to Use Destination Payments

Choose destination payments when:

* Your platform should appear on all customer statements (consistent branding)
* You want simplified accounting with automatic Application Fee tracking
* You need atomic guarantees that capture and transfer happen together
* Your business model is similar to Airbnb, Lyft, or other platform-centric marketplaces
* **You need to support merchants in regions outside Stripe's standard transfer countries** (when combined with scheduled transfers, destination payments can reach more countries)

## Impact on Payout Account Onboarding

Your transfer mechanism configuration directly affects which merchants can receive STRIPE payout accounts versus EXTERNAL payout accounts during onboarding. This is because different transfer mechanisms have different country support requirements.

### How Country Support Is Determined

| Transfer Mechanism       | Country Support Check                      | Technical Details                                                                                         |
| ------------------------ | ------------------------------------------ | --------------------------------------------------------------------------------------------------------- |
| **Standard Transfers**   | Stripe's supported transfer countries list | Uses the `supported_transfer_countries` from Stripe's CountrySpec API for your platform account's country |
| **Destination Payments** | Stripe's destination charge support        | Checks if "stripe" is in the `supported_payment_methods` for the merchant's country                       |

### Onboarding Outcomes

When a merchant connects to your app:

1. **If their country supports your transfer mechanism** → A STRIPE payout account is created (Express or Standard based on your configuration)
2. **If their country does NOT support your transfer mechanism** → An EXTERNAL payout account is created automatically

{% hint style="warning" %}
**Important**: The same country may have different support status depending on your transfer mechanism. For example, a country might support standard Stripe transfers but not destination charges.
{% endhint %}

### Example: Country Support Differences

Consider a merchant from Country X:

* **With Standard Transfers**: If Country X is in Stripe's supported transfer countries list, they get a STRIPE account
* **With Destination Payments**: If Country X doesn't support Stripe destination charges (even if it supports standard transfers), they get an EXTERNAL account

This means switching your transfer mechanism could change which of your merchants require EXTERNAL accounts.

For more details on payout account types and the onboarding flow, see [Prism Payout Accounts](/prism/payments/payouts/prism-payout-accounts.md).

## Configuration

Transfer mechanism settings can be configured at two levels:

* **App Level**: The default transfer mechanism for all merchants connected to your app
* **Merchant Level**: Override the app-level setting for specific merchants with different requirements

{% hint style="info" %}
**Ready to configure transfer mechanisms?** Transfer mechanism settings are managed by the Violet team. To learn more or configure a transfer mechanism for your app or specific merchants, please [reach out to Violet](mailto:support@violet.io).
{% endhint %}

## Related Documentation

* [Transfer Settings](/prism/payments/payment-settings/transfer-settings.md) - Configure when and how transfers are executed
* [Scheduled Transfers](/prism/payments/payment-settings/scheduled-transfers.md) - Configure fulfillment requirements and batched transfer schedules
* [Stripe Destination Charges](https://docs.stripe.com/connect/destination-charges) - Stripe's documentation on destination charges


---

# Agent Instructions: Querying This Documentation

If you need additional information that is not directly available in this page, you can query the documentation dynamically by asking a question.

Perform an HTTP GET request on the current page URL with the `ask` query parameter:

```
GET https://docs.violet.io/prism/payments/payment-settings/transfer-mechanisms.md?ask=<question>
```

The question should be specific, self-contained, and written in natural language.
The response will contain a direct answer to the question and relevant excerpts and sources from the documentation.

Use this mechanism when the answer is not explicitly present in the current page, you need clarification or additional context, or you want to retrieve related documentation sections.