Create subscription form — handle recurring payments easily

A subscription form is more than an order form — it initiates a recurring business relationship. Stripe offers a proven subscription API for this: you define a product, assign one or more prices (such as monthly and yearly) and create a subscription object per registration. The form collects the plan data and contact info, hands these over to the backend and triggers the Stripe checkout flow there.

Keep the form deliberately short. Plan selection, name, email and possibly company usually suffice; all further data is requested in the Stripe checkout — payment method, billing address, VAT ID. This is not only less work for you but also secure: Stripe is PCI-DSS certified, you yourself never have to come into contact with card data. After successful checkout, Stripe sends a webhook event to your backend that can activate the account or send access credentials. Do not rely on the browser success redirect alone — webhooks are the reliable source of truth.

In Germany, the UWG has since 2022 required a "cancellation button" for consumer contracts in electronic business. Anyone who can conclude a subscription online must also be able to end it online without hurdles — no login requirement, no phone call, no paper letter. Therefore build a simple cancellation workflow from the start. Your own cancellation form suffices: order ID or email, confirmation by mail, Stripe subscription is cancelled via API.

Communicate the cancellation conditions clearly in the registration form and in the order confirmation — minimum term, notice period, extension mechanism. A hidden "cancellation only by letter" note is not only unfriendly but also legally vulnerable. Anyone handling the subscription via Stripe can simply bind the cancellation button to the Stripe customer portal link — there Stripe has already integrated the mechanism. This saves in-house development and is accepted by the legislator. After cancellation, send a confirmation email with the end date and a note on data deletion.

Recurring payments process personal data over long periods — name, address, payment method, order history. The legal basis is Art. 6 (1) (b) GDPR (contract fulfillment), for marketing mailings additional consent is needed. Separate these two cleanly: the contract checkbox ("I agree to the terms") must not be merged with the marketing checkbox ("receive newsletter").

Store payment data exclusively with Stripe or a comparable PCI-DSS certified provider, never yourself. In your own system, the Stripe customer ID and subscription ID suffice — from these you can perform all required operations without seeing card data. At contract end, keep only the accounting-required data (in Germany ten years retention period) and delete the rest. Give customers a simple self-service portal where they can view, export and delete their data — that is a GDPR requirement and massively reduces support inquiries.

With recurring payments, it regularly happens that a booking fails — expired card, limit exceeded, account changed. Stripe offers so-called smart retries for this: the system automatically attempts the booking again over the next days, often successfully. Activate this function and configure a sensible retry scheme — typical are three to four attempts over seven days.

In parallel, you should inform the customer. With the first failed booking, a friendly email, with the second a clearer note, with the third the final notice before blocking. Stripe offers templates for this or you use your own email workflow via webhook. Also make updating the payment method easy: a self-service link in the Stripe customer portal suffices. Avoid aggressive dunning tones — most failed bookings are technical, not malicious. Anyone who is reminded kindly happily updates the card. Anyone treated harshly cancels rather. The conversion from recovery to continued subscription is often 60 to 70 percent with good workflows.