SaaS-Plattformzahlungen mit Abonnementabrechnung über Accounts v2Private Vorschau

Erfahren Sie, wie eine SaaS-Plattform ihre verbundenen Konten mit Stripe Billing über Accounts v2 belastet.

Software-as-a-Service-Plattformen (SaaS), die Connect verwenden, erheben häufig Abonnementgebühren für die Bereitstellung ihrer Plattformdienste. Accounts v1 erfordert, dass Plattformen separate Stripe-Objekte verwalten, damit ein einzelnes Unternehmen sowohl für ein Abonnement (als Customer) bezahlen als auch auf der Plattform (als Account) agieren kann. Mit Accounts v2 können Sie alle Ihre Interaktionen mit Ihren verbundenen Konten über ein einziges Objekt mit mehreren Konfigurationen verwalten.

Die Accounts v2 API

In der API v2 können Account-Objekte mehrere Konfigurationen haben. Jede Konfiguration stellt einen anderen Typ von Geschäftsbeziehung dar und ermöglicht unterschiedliche Stripe-Produkte. Durch Zuweisen mehrerer Konfigurationen zu einem Account kann eine SaaS-Plattform sowohl Connect als auch Billing für dieses Konto aktivieren, ohne dass ein/eine Customer erstellt werden muss.

Die Accounts v2 API bietet:

Einheitliche Darstellung: Ein einzelnes Account-Objekt kann mehrere Beziehungen zwischen verbundenen Konten und Ihrer Plattform darstellen.
Flexible Konfigurationen: Aktivieren oder ändern Sie Stripe-Produkte und -Funktionen, indem Sie die einem Account zugewiesenen Konfigurationen ändern.
Zentralisierte Identitätsdaten: Das Account-Objekt speichert alle Identitätsdaten eines verbundenen Kontos. Wenn Sie eine Konfiguration zu einem bestehenden Account hinzufügen, müssen Sie keine Anforderungen erfassen, die sie bereits bereitgestellt haben.

Beachten Sie beim Lesen der Dokumentation von Stripe die strukturellen Unterschiede zwischen einem Konto in API v2 und einem Konto in API v1. Zum Beispiel:

In API v2 sind einige Eigenschaften Teil der Konfigurations- oder Identitäts-Eigenschaften eines Kontos, die nur in Accounts v2 vorhanden sind.
Konten in API v2 stellen Funktionen wie card_payments und stripe_balance.stripe_transfers als features dar, die jeweils einem Konfigurationstyp zugeordnet sind. Konten in API v1 weisen ähnliche Funktionen auf wie capabilities.
In API v2 hat jede Anforderung ihre eigenen status-Eigenschaften. In API v1 enthält ein Konto Arrays für jeden Anforderungsstatus, und Anforderungen werden entsprechend ihrem Status in einem oder mehreren dieser Arrays angezeigt.

In der folgenden Tabelle wird veranschaulicht, wie einige Eigenschaften von Accounts v1 und Eigenschaften von Accounts v2 zugeordnet werden.

Accounts v1-Eigenschaft	Accounts v2-Eigenschaft
business_profile.url	identity.business_details.url
business_profile.support_url	configuration.merchant.support.url
business_profile.product_description	identity.business_details.product_description
Jede Anforderung wird je nach Status in einem oder mehreren Arrays angezeigt. requirements.currently_due requirements.eventually_due requirements.past_due	Jede Anforderung hat ihre eigenen `status`-Enum-Eigenschaften zum Einschränken von Funktionen und Auszahlungen sowie einen Mindest-`status`, der mit der früheren der beiden Anforderung übereinstimmt. Der Wert jedes `status` kann `currently_due`, `eventually_due` oder `past_due` sein. requirements.entries.impact.restricts_features.deadline.status requirements.entries.impact.restricts_payouts.deadline.status requirements.entries.minimum_deadline.status

Connect und Billing in API v1 mit Konten und Kundinnen/Kunden nutzen

In API v1 unterstützen Account-Objekte nur Connect-Funktionen. Um ein verbundenes Konto über ein Abonnement zu belasten, muss eine Plattform ein Customer-Objekt erstellen, dass dasselbe verbundene Konto darstellt. Accounts v1 und Customers v1 haben keine explizite Beziehung. Daher muss die Plattform diese Objekte getrennt voneinander verwalten und eine Zuordnung von Account-IDs zu Customer-IDs pflegen.

SaaS-Plattformbeziehungen mit Konten und Kundinnen/Kunden in API v1

Connect und Billing in API v2 mit Konten verwenden

Mit Accounts v2 benötigt ein verbundenes Konto, das Zahlungen einzieht und Ihnen eine Abonnementgebühr zahlt, nicht gleichzeitig ein Account-Objekt und ein Customer-Objekt. Stattdessen stellen Sie es dar, indem Sie dem vertreten Sie es, indem Sie dem Account die entsprechenden Konfigurationen zuweisen.

Um einem verbundenen Konto zu ermöglichen, Zahlungen von Kundinnen/Kunden einzuziehen, weisen Sie die Händlerkonfiguration dem entsprechenden Account zu.

Plattform und Konto mit Händlerkonfiguration

Um es der Plattform zu ermöglichen, Zahlungen, einschließlich Abonnementzahlungen, vom verbundenen Konto einzuziehen, fügen Sie dem Account die Kundenkonfiguration hinzu.

Plattform und Konto mit Händler- und Kundenkonfigurationen

Notiz

Sie können Plattformgebühren von einem Account mit der Händlerkonfiguration einziehen. Die Zuweisung der Kundenkonfiguration wirkt sich nicht auf diese Möglichkeit aus.

Überlegungen zur privaten Vorschau

Die private Vorschauversion von Accounts v2 weist einige Einschränkungen auf. Beachten Sie Folgendes:

Stripe-Produkte: Die Vorschau-Integration verwendet Billing, um Abonnementgebühren zu erheben, und Connect, um eingebettete Zahlungen zu ermöglichen.
Dashboard-Zugriff und Kontotypen: Ihre verbundenen Konten können das vollständige Dashboard oder das Express Stripe-Dashboard nicht verwenden. Erstellen Sie eine individuelle Nutzeroberfläche oder verwenden Sie nutzerdefinierte Benutzeroberfläche oder verwenden Sie in Connect eingebettete Komponenten.
Zahlungsmethoden: Accounts mit der Händlerkonfiguration können nur Kartenzahlungen akzeptieren. Sie können keine Wallet-Zahlungen oder Link-Zahlungen akzeptieren, unabhängig von der Link-Integration.
Zahlungstypen: Die Vorschau-Integration unterstützt nur Direct Charges und Destination Charges mit dem Parameter on_behalf_of. Sie können ohne on_behalf_of keine Destination Charges oder separaten Zahlungen und Überweisungen verwenden.