Set up a subscription with the related setting Direct Debit
Learn how to create and charge a subscription with the related setting Direct Debit.
A Checkout Session represents the details of your customer’s intent to purchase. You create a Checkout Session when your customer wants to start a subscription. After redirecting your customer to a Checkout Session, Stripe presents a payment form where your customer can complete their purchase. Once your customer has completed a purchase, they will be redirected back to your site.
Set up Stripe Server-side
Install the Stripe client of your choice:
Command Line
Select a language
Ruby
Python
PHP
Java
Node.js
Go
.NET
No results
# Available as a gem
sudo gem install stripe
Gemfile
Select a language
Ruby
Python
PHP
Java
Node.js
Go
.NET
No results
# If you use bundler, you can add this line to your Gemfile
gem 'stripe'
Install the Stripe CLI (optional). The CLI provides webhook testing, and you can run it to create your products and prices.
Install the Stripe CLI with npm:
Command Line
npm install -g @stripe/cli@latest
After installation, log in to your Stripe account:
Command Line
stripe login
After you install the CLI, you can also install agent tooling, or set up autocompletion.
Note
For more installation options for Windows, macOS, Linux, and Docker, see the Stripe CLI readme on GitHub.
Create the pricing model Dashboard Stripe CLI
Recurring pricing models represent the products or services you sell, how much they cost, what currency you accept for payments, and the service period for subscriptions. To build the pricing model, create products (what you sell) and prices (how much and how often to charge for your products).
This example uses flat-rate pricing with two different service-level options: Basic and Premium. For each service-level option, you need to create a product and a recurring price. To add a one-time charge for something like a setup fee, create a third product with a one-time price.
Each product bills at monthly intervals. The price for the Basic product is 5 EUR. The price for the Premium product is 15 EUR. See the flat rate pricing guide for an example with three tiers.
Go to the Add a product page and create two products. Add one price for each product, each with a monthly recurring billing period:
- Premium product: Premium service with extra features
- Price: Flat rate | 15 EUR
- Basic product: Basic service with minimum features
- Price: Flat rate | 5 EUR
After you create the prices, record the price IDs so you can use them in other steps. Price IDs look like this: price_G0FvDp6vZvdwRZ.
When you’re ready, use the Copy to live mode button at the top right of the page to clone your product from a sandbox to live mode.
For other pricing models, see Billing examples.
Create a Checkout Session Client-side Server-side
Add a checkout button to your website that calls a server-side endpoint to create a Checkout Session.
index.html
<html>
<head>
<title>Checkout</title>
</head>
<body>
<form action="/create-checkout-session" method="POST">
<button type="submit">Checkout</button>
</form>
</body>
</html>
Create a Checkout Session with the ID of an existing Price. Ensure that mode is set to subscription and you pass at least one recurring price. You can add one-time prices in addition to recurring prices. After creating the Checkout Session, redirect your customer to the URL returned in the response.
Command Line
Select a language
cURL
Ruby
Python
PHP
Java
Node.js
Go
.NET
No results
When your customer successfully completes their payment, they’re redirected to the success_url, a page on your website that informs the customer that their payment was successful. Make the Session ID available on your success page by including the {the related setting} template variable in the success_url as in the above example.
When your customer clicks on your logo in a Checkout Session without completing a payment, Checkout redirects them back to your website that the customer viewed prior to redirecting to Checkout.
Checkout Sessions expire 24 hours after creation by default.
From your Dashboard, enable the payment methods you want to accept from your customers. Checkout supports several payment methods.
Caution
Don’t rely on the redirect to the success_url alone for detecting payment initiation, because:
- Malicious users could directly access the success _ url without paying and gain access to your goods or services.
- After a successful payment, customers might close their browser tab before they’re redirected to the success _ url .
Confirm the payment is successful
When your customer completes a payment, Stripe redirects them to the URL that you specified in the success_url parameter. Typically, this is a page on your website that informs your customer that their payment was successful.
However, the related setting Direct Debit is a delayed notification payment method, which means that funds aren’t immediately available. Delay order fulfillment until the payment succeeds. Don’t use the subscription status alone because a subscription can become active while its first payment is still processing. Before fulfilling goods or services, wait for the invoice.paid event or confirm that the underlying PaymentIntent has a succeeded status, and verify that the related subscription is active.
You can confirm the payment is successful in several ways:
Successful payments display in the Dashboard’s list of payments. When you click a payment, it takes you to the payment details page. The Checkout summary section contains billing information and the list of items purchased, which you can use to manually fulfill the order.
Note
Stripe can help you keep up with incoming payments by sending you email notifications whenever a customer successfully completes one. Use the Dashboard to configure email notifications.
Test the integration
You can test your integration using the IBANs below. The payment method details are successfully collected for each the related setting but exhibit different behavior when charged.
Test IBANs
Use these test IBANs with the Payment Element to test your the related setting Direct Debit integration. The Payment Element automatically validates the the related setting and displays the mandate when you enter one of these test values.
| Account Number | Token | Description |
|---|---|---|
the related setting | pm_sepaDebit_success_at | The PaymentIntent status transitions from processing to succeeded. |
the related setting | pm_sepaDebit_successDelayed_at | The PaymentIntent status transitions from processing to succeeded after at least three minutes. |
the related setting | pm_sepaDebit_failed_at | The PaymentIntent status transitions from processing to requires_payment_method. |
the related setting | pm_sepaDebit_failedDelayed_at | The PaymentIntent status transitions from processing to requires_payment_method after at least three minutes. |
the related setting | pm_sepaDebit_disputed_at | The PaymentIntent status transitions from processing to succeeded, but a dispute is immediately created. |
the related setting | pm_sepaDebit_exceedsWeeklyVolumeLimit_at | The payment fails with a charge_exceeds_source_limit failure code due to payment amount causing account to exceed its weekly payment volume limit. |
the related setting | pm_sepaDebit_exceedsWeeklyTransactionLimit_at | The payment fails with a charge_exceeds_weekly_limit failure code due to payment amount exceeding account's transaction volume limit. |
the related setting | pm_sepaDebit_insufficientFunds_at | The payment fails with an insufficient_funds failure code. |
the related setting | Payment method creation fails with a bank_account_unusable error. Use a different bank account or payment method. Applies to SetupIntents and PaymentIntents that include inline the related setting data. |
