Skip to content

Checkout & Submission

These components handle the final submission step of a questionnaire — either with payment (GenericCheckout) or without (GenericSubmission).


The Stripe payment integration page. This is the last step before a policy is created, where the user reviews their selections and enters payment details.

Layout: Standalone

The checkout page displays:

  1. Policy summary — Key-value pairs showing the user’s selections (e.g., “Coverage: Premium”, “Start date: 01.01.2025”)
  2. Product card — Product icon, name, and monthly/yearly price
  3. Price breakdown — Itemized list of costs (base price, add-ons, discounts)
  4. Billing options — Toggle between monthly and yearly payment cycles
  5. Stripe payment form — SEPA direct debit or credit card entry (rendered by Stripe Elements)
  6. Legal footnotes — Billing-related disclaimers
Prop Type Description
policyDetails array Key-value pairs for the summary. Each entry has key (a question ID whose answer is displayed) and label (the display label).
productCardDetails object Product card content: icon, product name, and pricing display configuration
additionalPolicyDetails array Grouped sections of extra information below the main summary. Each group has a title and its own list of key-value pairs.
priceBreakdown array Itemized price rows. Each entry maps a pricing component to a display label.
contractCycleYearly object Configuration for the yearly billing option (label, discount text)
contractCycleMonthly object Configuration for the monthly billing option
billingFootnote string Legal text displayed below the payment form
icon string Product icon displayed in the checkout header
  1. The component reads the user’s questionnaire answers and maps them to the display using policyDetails
  2. It fetches the current price from the pricing engine
  3. The user selects a billing cycle (if both monthly and yearly are configured)
  4. The user enters payment details via the embedded Stripe form
  5. On submission, the app sends the payment method and questionnaire data to the backend
  6. The backend creates the policy and charges the customer
  7. On success, the questionnaire navigates to the next question (typically a Processing or Success screen)

Non-payment form submission. Used for flows that collect information without requiring payment — lead generation, claims filing, or free product signups.

Layout: Standalone

A simplified version of the checkout page:

  1. Submission summary — Key-value pairs from the user’s answers
  2. Product card — Product information (without pricing)

No payment form is shown.

Prop Type Description
policyDetails array Key-value pairs for the summary. Same format as GenericCheckout.
productCardDetails object Product card content
additionalPolicyDetails array Grouped sections of extra details
  1. The component renders a summary of the user’s answers
  2. On submission, the app posts the collected data to the backend API
  3. The backend processes the submission (creates a lead, files a claim, etc.)
  4. On success, the questionnaire navigates to the next question