Collect payments then pay out

Install Stripe’s official libraries to access the API from your application:

# Available as a gem
sudo gem install stripe

# If you use bundler, you can add this line to your Gemfile
gem 'stripe'

When a user (seller or service provider) signs up on your marketplace, you must create a corresponding user Account (referred to as a connected account). You can’t accept payments and move funds to the bank account of your user without a connected account. Connected accounts represent your users in the Stripe API and collect the information required to verify the user’s identity. In our home-rental example, the connected account represents the homeowner.

Create an Express connected account and prefill information

Use the /v1/accounts API to create an Express account and set type to express in the account creation request.

curl https://api.stripe.com/v1/accounts \
  -u 
sk_test_4eC39HqLyjWDarjtT1zdp7dc: \
  -d type=express

If you’ve already collected information for your connected accounts, you can prefill that information on the account object for the user and it won’t be collected again in the Connect Onboarding flow. Any information on the account can be prefilled, including company or individual information, external account information, and more.

Create an account link

You can create an account link by calling the Account Links API with the following parameters:

• account
• refresh_url
• return_url
• type = account_onboarding

curl https://api.stripe.com/v1/account_links \
  -u 
sk_test_4eC39HqLyjWDarjtT1zdp7dc: \
  -d account=acct_1032D82eZvKYlo2C \
  -d refresh_url="https://example.com/reauth" \
  -d return_url="https://example.com/return" \
  -d type=account_onboarding

Redirect your user to the account link URL

The response to your Account Links request includes a value for the key url. Redirect to this link to send your user into the flow. URLs from the Account Links API are temporary and are single-use only, because they grant access to the connected account user’s personal information. Authenticate the user in your application before redirecting them to this URL. If you want to prefill information, you must do so before generating the account link. After you create the account link for an Express account, you can’t read or write information for the account.

Handle the user returning to your platform

Connect Onboarding requires you to pass both a return_url and refresh_url to handle all cases where the user is redirected to your platform. It’s important that you implement these correctly to provide the best experience for your user.

return_url

Stripe issues a redirect to this URL when the user completes the Connect Onboarding flow. This doesn’t mean that all information has been collected or that there are no outstanding requirements on the account. This only means the flow was entered and exited properly.

No state is passed through this URL. After a user is redirected to your return_url, check the state of the details_submitted parameter on their account by doing either of the following:

• Listening to account.updated webhooks
• Calling the Accounts API and inspecting the returned object

refresh_url

Stripe redirects your user to the refresh_url in these cases:

• The link is expired (a few minutes went by since the link was created).
• The user already visited the URL (the user refreshed the page or clicked back or forward in the browser).
• Your platform is no longer able to access the account.
• The account has been rejected.

Your refresh_url should trigger a method on your server to call Account Links again with the same parameters, and redirect the user to the Connect Onboarding flow to create a seamless experience.

Handle users that haven’t completed onboarding

A user that’s redirected to your return_url might not have completed the onboarding process. Use the /v1/accounts endpoint to retrieve the user’s account and check for charges_enabled. If the account isn’t fully onboarded, provide UI prompts to allow the user to continue onboarding later. The user can complete their account activation through a new account link (generated by your integration). You can check the state of the details_submitted parameter on their account to see if they’ve completed the onboarding process.

View your payment methods settings and enable the payment methods you want to support. Card payments, Google Pay, and Apple Pay are enabled by default but you can enable and disable payment methods as needed.

Before the payment form is displayed, Stripe evaluates the currency, payment method restrictions, and other parameters to determine the list of supported payment methods. Payment methods that increase conversion and that are most relevant to the currency and customer’s location are prioritized. Lower priority payment methods are hidden in an overflow menu.

We recommend using Stripe Checkout, a prebuilt Stripe-hosted page, to accept payments. Checkout supports multiple payment methods and automatically shows the most relevant ones to your customer. You can also use the Payment Element, a prebuilt UI component that is embedded as an iframe in your payment form, to accept multiple payment methods with a single frontend integration.

Checkout

Payment Element

Create a Checkout Session Client and Server

A Checkout Session controls what your customer sees in the Stripe-hosted payment page such as line items, the order amount and currency, and acceptable payment methods.

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, make the following call to Stripe’s API. After creating a Checkout Session, redirect your customer to the URL returned in the response.

curl

Ruby

Python

PHP

Node

Java

Go

.NET

Terminal

curl https://api.stripe.com/v1/checkout/sessions \
  -u 
sk_test_4eC39HqLyjWDarjtT1zdp7dc
: \
  -d "line_items[][price]"=
"{{PRICE_ID}}" \
  -d "line_items[][quantity]"=1 \
  -d "mode"="payment" \
  -d "success_url"="https://example.com/success" \
  -d "cancel_url"="https://example.com/cancel" \
  -d "payment_intent_data[application_fee_amount]"=123 \
  -d "payment_intent_data[transfer_data][destination]"=
"{{CONNECTED_ACCOUNT_ID}}"

• line_items - This argument represents the items the customer is purchasing. The items are displayed in the Stripe-hosted user interface.
• success_url - This argument redirects a user after they complete a payment.
• cancel_url - This argument redirects a user after they click cancel.
• payment_intent_data[application_fee_amount] - This argument specifies the amount your platform plans to take from the transaction. The full charge amount is immediately transferred from the platform to the connected account that’s specified by transfer_data[destination] after the charge is captured. The application_fee_amount is then transferred back to the platform, and the Stripe fee is deducted from the platform’s amount.
• payment_intent_data[transfer_data][destination] - This argument indicates that this is a destination charge. A destination charge means the charge is processed on the platform and then the funds are immediately and automatically transferred to the connected account’s pending balance. For our home-rental example, we want to build an experience where the customer pays through the platform and the homeowner gets paid by the platform.

When performing destination charges, Checkout uses the brand settings of your platform account. See the Customize branding section for more information.

This Session creates a destination charge. If you need to control the timing of transfers or need to transfer funds from a single payment to multiple parties, use separate charges and transfers instead.

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, like 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.

In addition to handling the checkout.session.completed event, we recommend handling two other events when collecting payments with Checkout:

Event	Description	Next steps
checkout.session.completed	The customer has successfully authorized 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.	Fulfill 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 request that they 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.

Test your account creation flow by creating accounts and using OAuth.

Use test payment details and the test redirect page to verify your integration. Click the tabs below to view details for each payment method.