Create direct charges

Create charges directly on the connected account and collect fees.

Create direct charges when customers transact directly with a connected account, often unaware of your platform’s existence. With direct charges:

The payment appears as a charge on the connected account, not your platform’s account.
The connected account’s balance increases with every charge.
Your account balance increases with application fees from every charge.

This charge type is best suited for platforms providing software as a service. For example, Shopify provides tools for building online storefronts, and Thinkific enables educators to sell online courses.

Note

We recommend using direct charges for connected accounts that have access to the full Stripe Dashboard.

Web

iOS

Android

React Native

Redirect to a Stripe-hosted payment page using Stripe Checkout. See how this integration compares to Stripe’s other integration types.

Integration effort

Low code

Integration type

Redirect to Stripe-hosted payment page

UI customisation

Limited customisation

Try it out

First, register for a Stripe account.

Use our official libraries to access the Stripe API from your application:

Create a Checkout Session
Client-side
Server-side

A Checkout Session controls what your customer sees in the payment form such as line items, the order amount, and currency. Add a checkout button to your website that calls a server-side endpoint to create a Checkout Session.

checkout.html
<html>
  <head>
    <title>Checkout</title>
  </head>
  <body>
    <form action="/create-checkout-session" method="POST">
      <button type="submit">Checkout</button>
    </form>
  </body>
</html>

On your server, create a Checkout Session and redirect your customer to the URL returned in the response.

line_items - This attribute represents items that your customer is purchasing and appears in the Stripe-hosted checkout page.
payment_intent_data[application_fee_amount] - This attribute specifies the amount your platform deducts from the transaction as an application fee. After the payment is processed on the connected account, the application_fee_amount is transferred to the platform. See collect fees for more information.
success_url – Stripe redirects the customer to the success URL after they complete a payment and replaces the {CHECKOUT_SESSION_ID} string with the Checkout Session ID. Use this to retrieve the Checkout Session and inspect the status to decide what to show your customer. You can also append your own query parameters, which persist through the redirect process. See customise redirect behaviour with a Stripe-hosted page for more information.
Stripe-Account - This header indicates a direct charge for your connected account. The connected account’s branding is used in Checkout, which allows their customers to feel like they’re interacting directly with the connected account instead of your platform.

Charges that you create directly on the connected account are reported only on that account. These charges aren’t shown in your platform’s Dashboard or exports. Direct charges are included in reports and Sigma for connected accounts that your platform controls. You can always retrieve this information using the Stripe API.

Handle post-payment events
Server-side

Stripe sends a checkout.session.completed event when the payment completes. Use a webhook to receive these events and run actions, such as sending an order confirmation email to your customer, logging the sale in a database, or starting a shipping workflow.

Listen for these events rather than waiting on a callback from the client. On the client, the customer could close the browser window or quit the app before the callback executes. Some payment methods also take 2-14 days for payment confirmation. Setting up your integration to listen for asynchronous events enables you to accept multiple payment methods with a single integration.

Stripe recommends handling all the following events when collecting payments with Checkout:

Event	Description	Next steps
checkout.session.completed	The customer has successfully authorised the payment by submitting the Checkout form.	Wait for the payment to succeed or fail.
checkout.session.async_payment_succeeded	The customer’s payment succeeded.	Fulfil the purchased goods or services.
checkout.session.async_payment_failed	The payment was declined, or failed for some other reason.	Contact the customer through email and ask them to place a new order.

These events all include the Checkout Session object. After the payment succeeds, the underlying PaymentIntent status changes from processing to succeeded or a failure status.

Test the integration

Card number	Scenario	How to test
	The card payment succeeds and doesn’t require authentication.	Fill in the credit card form using the credit card number with any expiry date, CVC, and postal code.
	The card payment requires authentication.	Fill in the credit card form using the credit card number with any expiry date, CVC, and postal code.
	The card is declined with a decline code like `insufficient_funds`.	Fill in the credit card form using the credit card number with any expiry date, CVC, and postal code.
	The UnionPay card has a variable length of 13-19 digits.	Fill in the credit card form using the credit card number with any expiry date, CVC, and postal code.

See Testing for additional information to test your integration.

OptionalEnable additional payment methods

Navigate to Manage payment methods for your connected accounts in the Dashboard to configure which payment methods your connected accounts accept. Changes to default settings apply to all new and existing connected accounts.

Consult the following resources for payment method information:

A guide to payment methods to help you choose the correct payment methods for your platform.
Account capabilities to make sure your chosen payment methods work for your connected accounts.
Payment method and product support tables to make sure your chosen payment methods work for your Stripe products and payments flows.

For each payment method, you can select one of the following dropdown options:

On by default	Your connected accounts accept this payment method during checkout. Some payment methods can only be off or blocked. This is because your connected accounts with access to the Stripe Dashboard must activate them in their settings page.
Off by default	Your connected accounts don’t accept this payment method during checkout. If you allow your connected accounts with access to the Stripe Dashboard to manage their own payment methods, they have the ability to turn it on.
Blocked	Your connected accounts don’t accept this payment method during checkout. If you allow your connected accounts with access to the Stripe Dashboard to manage their own payment methods, they don’t have the option to turn it on.

Dropdown options for payment methods, each showing an available option (blocked, on by default, off by default)

Payment method options

If you make a change to a payment method, you must click Review changes in the bottom bar of your screen and Save and apply to update your connected accounts.

Window that shows after clicking Save button with a list of what the user changed

Save window

Allow connected accounts to manage payment methods

Stripe recommends allowing your connected accounts to customise their own payment methods. This option allows each connected account with access to the Stripe Dashboard to view and update their Payment methods page. Only owners of the connected accounts can customise their payment methods. The Stripe Dashboard displays the set of payment method defaults you applied to all new and existing connected accounts. Your connected accounts can override these defaults, excluding payment methods you have blocked.

Tick the Account customisation tickbox to enable this option. You must click Review changes in the bottom bar of your screen and then select Save and apply to update this setting.

Screenshot of the tickbox to select when allowing connected owners to customise payment methods

Account customisation tickbox

Payment method capabilities

To allow your connected accounts to accept additional payment methods, you must make sure their connected accounts have active capabilities for each payment method. Most payment methods have the same verification requirements as the card_payments capability, with some restrictions and exceptions. The payment method capabilities table lists the payment methods that require additional verification over cards.

Navigate to the Connected account payment settings in the Dashboard to request capabilities on your new and existing connected accounts for each payment method and country combination.

Collect fees

When a payment is processed, your platform can take a portion of the transaction in the form of application fees. You can set application fee pricing in two ways:

Use the Platform Pricing Tool to set and test pricing rules. This no-code feature in the Stripe Dashboard is currently only available for platforms responsible for paying Stripe fees.
Set your pricing rules in-house, specifying application fees directly in a PaymentIntent. Fees set with this method override the pricing logic specified in the Platform Pricing Tool.

Your platform can take an application fee with the following limitations:

The value of application_fee_amount must be positive and less than the amount of the charge. The application fee collected is capped at the captured amount of the charge.
There are no additional Stripe fees on the application fee itself.
In line with Brazilian regulatory and compliance requirements, platforms based outside Brazil, with Brazilian connected accounts can’t collect application fees through Stripe.
The currency of application_fee_amount depends upon a few multiple currency factors.

The resulting charge’s balance transaction includes a detailed fee breakdown of both the Stripe and application fees. To provide a better reporting experience, an Application Fee is created after the fee is collected. Use the amount property on the application fee object for reporting. You can then access these objects with the Application Fees endpoint.

Earned application fees are added to your available account balance on the same schedule as funds from regular Stripe charges. Application fees are viewable in the Collected fees section of the Dashboard.

Caution

Application fees for direct charges are created asynchronously by default. If you expand the application_fee object in a charge creation request, the application fee is created synchronously as part of that request. Only expand the application_fee object if you must, because it increases the latency of the request.

To access the application fee objects for application fees that are created asynchronously, listen for the application_fee.created webhook event.

Flow of funds with fees

When you specify an application fee on a charge, the fee amount is transferred to your platform’s Stripe account. When processing a charge directly on the connected account, the charge amount—less the Stripe fees and application fee—is deposited into the connected account.

For example, if you make a charge of 10 USD with a 1.23 USD application fee (like in the previous example), 1.23 USD is transferred to your platform account. 8.18 USD (10 USD - 0.59 USD - 1.23 USD) is netted in the connected account (assuming standard US Stripe fees).

Flow of funds for a charge with an application fee

If you process payments in multiple currencies, read how currencies are handled in Connect.

Customise branding

Your platform and connected accounts can use the Branding settings in the Dashboard to customise branding on the payments page. For direct charges, Checkout uses the brand settings of the connected account.

You can also use the API to update branding settings:

icon - Displayed next to the business name in the header of the Checkout page.
logo - Used in place of the icon and business name in the header of the Checkout page.
primary_color - Used as the background colour on the Checkout page.
secondary_color - Used as the button colour on the Checkout page.

Issue refunds

Just as platforms can create charges on connected accounts, they can also create refunds of charges on connected accounts. Create a refund using your platform’s secret key while authenticated as the connected account.

Application fees are not automatically refunded when issuing a refund. Your platform must explicitly refund the application fee or the connected account—the account on which the charge was created—loses that amount. You can refund an application fee by passing a refund_application_fee value of true in the refund request:

By default, the entire charge is refunded, but you can create a partial refund by setting an amount value as a positive integer. If the refund results in the entire charge being refunded, the entire application fee is refunded. Otherwise, a proportional amount of the application fee is refunded. Alternatively, you can provide a refund_application_fee value of false and refund the application fee separately.

Connect embedded components

Connect embedded components support direct charges. By using the payments embedded component, you can let your connected accounts view payment information, capture charges, and manage disputes from within your site.

The following components display information for direct charges:

Payments component: Displays all of an account’s payments and disputes.
Payments details: Displays information for a specific payment.
Disputes list component: Displays all of an account’s disputes.
Disputes for a payment component: Displays the disputes for a single specified payment. You can use it to include dispute management functionality on a page with your payments UI.