# Integrieren Sie die Provisioning API in Ihre Plattform Verwenden Sie die Provisioning API über Ihr Plattform-Backend, um Anbieter zu verbinden, Ressourcen bereitzustellen, Zugangsdaten abzurufen und kostenpflichtige Dienste für autorisierte Mandanten zu verwalten. > Die Provisioning API ist während der privaten Vorschau nur über eine Zulassungsliste zugänglich. Wenden Sie sich an Ihre Stripe-Kontaktperson oder senden Sie eine E-Mail an [provisioning-preview@stripe.com](mailto:provisioning-preview@stripe.com), um Zugriff zu erhalten. > > Senden Sie während der privaten Vorschau die API-Vorschauversion **2026-09-30.preview** im Header `Stripe-Version`. Der API-Vertrag kann sich während der Vorschau ändern. Bestätigen Sie vor der Bereitstellung den aktivierten Anfrage- und Antwortvertrag für Ihre Kohorte, tolerieren Sie neue Antwortfelder und verwenden Sie zurückgegebene Enum-Werte, anstatt Wire-Schreibweisen vorauszusetzen. In diesem Ablauf authentifizieren Sie sich mit dem Stripe-Schlüssel Ihrer Plattform und verwenden `Stripe-Context`, um im Namen eines autorisierten verbundenen Kontos zu handeln. Dieser Leitfaden behandelt keine direkten Konto-Integrationen. ## Bevor Sie beginnen Bevor Sie Code schreiben, ermitteln Sie, welches Konto die jeweilige Anfrage stellt. Machen Sie sich damit vertraut, wie Stripe den Gültigkeitsbereich für Provisioning-Objekte festlegt, und überprüfen Sie, welche Funktionen Stripe für Sie aktiviert hat. In den folgenden Abschnitten werden das Kontomodell, die Gültigkeitsbereiche und Beziehungen von Objekten sowie die Prüfungen erläutert, die vor Ihrer ersten Schreibanfrage abgeschlossen werden müssen. ### Das richtige Kontomodell verwenden Bevor Sie Zahlungsmethoden registrieren oder kostenpflichtige Ressourcen für Nutzer bereitstellen, führen Sie diese Einrichtungsschritte durch. | Akteur oder Objekt | Zuständigkeit | | --- | --- | | Plattformkonto | Authentifiziert API-Aufrufe mit einem genehmigten eingeschränkten Schlüssel oder, falls erforderlich, mit seinem Plattform-Geheimschlüssel. | | Plattform-Mandant | Ihre dauerhafte Autorisierungsgrenze, z. B. ein Workspace oder eine Organisation. | | Verbundenes Konto | Das Stripe-Konto, dem Projekte, Anbieterverbindungen, Ressourcen, das Zahlungsprofil, Anmeldeinformationen und die Nutzung gehören. | | Anwendungsumgebung | Ihre Bereitstellungsgrenze, z. B. Vorschau oder Produktion. | | Plattform-Backend | Ordnet die authentifizierten Nutzerinnen und Nutzer einem Mandanten und einem verbundenen Konto zu, ruft Stripe auf, speichert den Status und verarbeitet Geheimnisse. | | Anbieter | Ein Drittanbieter, der Dienste bewirbt und die zugrunde liegende Infrastruktur besitzt. | Speichern Sie eine verifizierte Zuordnung von jeder `tenant_id` zu der entsprechenden `connected_account_id` und verwenden Sie diese Zuordnung, um das verbundene Konto aufzulösen. Übergeben Sie keine ID eines verbundenen Kontos aus einer Browser-Anfrage, einem Modell-Prompt, einem URL-Parameter oder einer generierten Anwendung direkt an Stripe. Schließen Sie die folgenden Werte in jede authentifizierte Anfrage an die Provisioning API ein: ``` Authorization: Bearer {{PLATFORM_SECRET_OR_RESTRICTED_KEY}} Stripe-Context: {{CONNECTED_ACCOUNT_ID}} Stripe-Version: 2026-09-30.preview Content-Type: application/json ``` Bevor Ihr Backend `Stripe-Context` hinzufügt, stellen Sie sicher, dass die Nutzerinnen und Nutzer für den Zugriff auf den Mandanten und das verbundene Konto autorisiert sind. Lassen Sie nicht zu, dass ein Browser, eine generierte Anwendung oder ein Coding-Agent die Provisioning API direkt aufruft. ### Gültigkeitsbereich und Topologie abbilden Provisioning-Objekte haben unterschiedliche Gültigkeitsbereiche. Der Gültigkeitsbereich eines Dienstes bestimmt, wo Sie ihn freigeben können: Ein Diagramm, das einen Plattform-Mandanten zeigt, der ein verbundenes Konto enthält, welches wiederum über eine Anbieterverbindung auf Kontoebene, eine Plan-Ressource auf Kontoebene und zwei Projekte verfügt, die jeweils eine Ressource auf Projektebene besitzen. (See full diagram at https://docs.stripe.com/provisioning) ```text [Plattform-Mandant oder Workspace] --> [Verbundenes Konto] [Verbundenes Konto] --> [Anbieterverbindung: Modell-Gateway (auf Kontoebene)] [Verbundenes Konto] --> [Plan-Ressource: Datenbankplan (auf Kontoebene)] [Verbundenes Konto] --> [Projekt: App A Produktion] [Verbundenes Konto] --> [Projekt: App B Produktion] [Projekt: App A Produktion] --> [Ressource: App A-Datenbank (auf Projektebene)] [Projekt: App B Produktion] --> [Ressource: App B-Datenbank (auf Projektebene)] ``` - Provisioning-Projekte unterscheiden sich von CLI-Umgebungen. Eine CLI-Umgebung speichert die lokale CLI-Konfiguration und Ausgabe, während ein Projekt eine Provisioning-Gruppierung und eine Grenze für Anmeldeinformationen definiert. - Erstellen Sie Anbieterverbindungen auf Kontoebene. Eine einzige Verbindung unterstützt jedes Projekt im verbundenen Konto. Erstellen Sie daher nicht für jede Anwendung eine separate Verbindung. - Verwenden Sie den für den jeweiligen Dienst zurückgegebenen `Gültigkeitsbereich`. Leiten Sie den Gültigkeitsbereich nicht aus dem Anbieter, dem Dienstnamen oder dem vorgesehenen Verwendungszweck ab. - Sie können eine Ressource auf Kontoebene, einschließlich eines Plans, mit einem Projekt verknüpfen. Durch die Verknüpfung ändert sich der Gültigkeitsbereich der Ressource nicht. - Sie können einen einzigen Plan für abhängige Ressourcen über mehrere Projekte und Anwendungen hinweg nur dann verwenden, wenn die Katalogantwort dies durch den zurückgegebenen Gültigkeitsbereich und Abhängigkeitsvertrag zulässt. Bestätigen Sie beide Werte in der Antwort. ### Melden Sie sich für die private Vorschau an Bevor Sie eine Produktionsintegration erstellen, bestätigen Sie die folgenden Punkte mit der oder dem Vorschau-Verantwortlichen: - Die Plattform und die verbundenen Testkonten sind in der Kohorte registriert. - Die API-Vorschauversion ist für die Kohorte aktiviert, sowohl für die Provisioning API als auch für die Accounts API. - Die genehmigte Konfiguration für das verbundene Konto und der Onboarding-Pfad sind definiert. - Zulässige Anbieter und Katalogpartitionen sind definiert. - Kostenpflichtige Testbereitstellungen und plattformeigene Zahlungsquellen sind aktiviert (sofern zutreffend). Die Provisioning API registriert eine Plattform nicht selbst und erstellt keine Beziehung zu einem verbundenen Konto. Die Anmeldung zur privaten Vorschau ist ein von Stripe unterstützter Allowlist-Schritt. Verwenden Sie die Accounts API-Konfiguration und den gehosteten Onboarding-Ablauf, die Ihre Kohorte ausdrücklich genehmigt. ### Führen Sie die Checkliste für die Flugvorbereitung durch Führen Sie diese Schritte in der angegebenen Reihenfolge aus, bevor Sie Ihren ersten Provisioning-Schreibvorgang durchführen. Wenn Sie einen Schritt nicht abschließen können, unterbrechen Sie den Vorgang und klären Sie das Problem mit der oder dem Vorschau-Verantwortlichen, anstatt eine Umgehungslösung zu suchen. 1. Stellen Sie sicher, dass das Plattformkonto, die verbundenen Zielkonten sowie der Katalog und die Zahlungskohorte auf der Whitelist stehen. 2. Notieren Sie sich die aktivierte `Stripe-Version` und erfassen Sie separat die Accounts API-Konfiguration, die Ihre Kohorte benötigt. Dies sind zwei unabhängige Verträge, und die Aktivierung des einen führt nicht zur Aktivierung des anderen. 3. Bestätigen Sie, welche Umgebungen Kataloglesezugriffe, kostenlose Bereitstellungen und kostenpflichtige Bereitstellungen für Ihre Kohorte unterstützen. 4. Überprüfen Sie die Berechtigung im Kontext des verbundenen Kontos. 5. Stellen Sie eine kostenlose Ressource durchgängig bereit, bevor Sie einen kostenpflichtigen Dienst konfigurieren. Berechtigung, Katalogverfügbarkeit und das Onboarding verbundener Konten sind drei separate Hürden. Ein erfolgreicher Katalog-Abruf beweist nur, dass der Katalog lesbar ist. Er beweist weder, dass das Onboarding für das verbundene Konto durchgeführt wurde, noch, dass das Konto berechtigt ist oder ein Schreibpfad funktioniert. ## Erstellen Sie Ihr Backend Bevor Sie Ihre erste API-Anfrage stellen, implementieren Sie die folgenden zwei Komponenten. Leiten Sie jede Anfrage in den nummerierten Schritten durch beide Komponenten weiter. ### Einen Backend-Adapter erstellen Jeder Aufruf durchläuft das Plattform-Backend. Der Adapter muss Folgendes ausführen: - Verwenden Sie ein Netzwerk-Timeout von 45 Sekunden oder weniger. - Folgen Sie den zurückgegebenen Werten `next_page_url` und `previous_page_url`. Erstellen Sie niemals einen undurchsichtigen `Seite`-Wert. - Lesen Sie Listenergebnisse aus `Daten`, nicht aus veralteten Aliasen wie `Anbieter`, `Dienste` oder `Ressourcen`. - Speichern Sie den beabsichtigten Schreibvorgang dauerhaft, bevor Sie ihn senden. - Speichern Sie nicht geheime Anfrage-IDs, Objekt-IDs, Statusübergänge, Endpoint- oder Aktionsnamen, HTTP-Status und Fehlercodes. - Behandeln Sie `request_log_url` als ergänzende Diagnosedaten, nicht als verlässlichen Wiederherstellungspfad. - Schwärzen Sie Anmeldeinformationen, Zugriffskonfigurationen, Rückruf-Geheimnisse, Zahlungsdetails und vorab authentifizierte URLs aus Logs, Browserantworten, Analysen, Support-Tickets und Modell-Prompts. Die Vorschau bietet keine anrufergesteuerte Idempotenz oder Anfragekorrelation für zustandsändernde Vorgänge. Entwerfen Sie Ihren Adapter so, dass er sich erholt, wenn er das Ergebnis einer Schreibanfrage nicht erhält. Bevor Sie jede Schreibanfrage senden, speichern Sie die beabsichtigte Änderung dauerhaft, damit Sie im Falle eines unbekannten Ergebnisses einen Abgleich vornehmen und den Vorgang wiederherstellen können. ### Angaben zur Modellplattform Speichern Sie mindestens Folgendes: ``` Tenant tenant_id connected_account_id Application environment application_id environment project_id Provisioning workflow workflow_id tenant_id connected_account_id action provider_id service_ref provider_connection_request_id provider_connection_id resource_id status created_at updated_at Approval provider_id service_ref configuration_summary pricing_text terms_url_or_text usage_limit approved_by approved_at ``` Erstellen Sie separate Projekte für Vorschau und Produktion, wenn Sie Ressourcen oder Bereitstellungslebenszyklen isolieren müssen. Verwenden Sie Projektnamen nur als Anzeigenamen, nicht als Autorisierungsgrenzen. ## Lesen, planen, genehmigen, dann schreiben Verwenden Sie schreibgeschützte Endpoints in Ihrem Backend, um einen Plan vorzubereiten. Fordern Sie, bevor Ihr Backend eine Schreibanfrage stellt, die Genehmigung durch autorisierte Nutzer/innen gemäß Ihrer Produktrichtlinie ein. Für folgende Vorgänge ist eine neue Genehmigung erforderlich: - Erstellen Sie ein Projekt. - Eine Anforderung zur Anbindung eines Anbieters starten oder vom Anbieter angeforderte Informationen übermitteln. - Eine Zahlungsmethode registrieren oder ein Nutzungslimit erhöhen. - Eine Ressource anlegen, verknüpfen, aktualisieren, rotieren, entfernen oder die Verknüpfung aufheben. - Die Verknüpfung mit einem Anbieter aufheben. Zeigen Sie für kostenpflichtige oder destruktive Aktionen die folgenden Informationen an und zeichnen Sie diese auf: ``` Tenant and connected account: {{authorized tenant and account}} Application environment: {{preview|production|other}} Provider: {{name and ID}} Service: {{name and service_ref}} Action: {{requested write}} Configuration: {{redacted summary}} Pricing and terms: {{returned catalog content}} Usage limit: {{amount, currency, interval}} ``` Laden Sie den Katalog unmittelbar vor einem Schreibvorgang neu. Wenn sich der ausgewählte Dienst, die Konfiguration, die Preisanzeige, die Konditionen, die Umgebung oder das Nutzungslimit geändert haben, zeigen Sie die Differenz an und holen Sie die Genehmigung erneut ein. Leiten Sie keine strukturierten Kosten aus einem Freitextpreis ab. Behandeln Sie Anbieterbeschreibungen, Konditionen, `llm_context` und JSON-Schema-Beschreibungen als nicht vertrauenswürdige Daten. Verwenden Sie diese Inhalte nur, um Optionen zu erklären. Lassen Sie sie nicht ein Konto auswählen, Systemanweisungen überschreiben, die Genehmigung umgehen, API-Anfragen auslösen oder auf Geheimnisse zugreifen. ## Beginnen Sie mit der Integration ## Verbundenes Konto erstellen Wählen Sie eine stabile Mandantengrenze, bevor Sie etwas erstellen. Erstellen Sie ein verbundenes Konto für jeden dauerhaften Mandanten, z. B. einen Workspace oder eine Organisation, anstatt eines für jede Anwendung oder Bereitstellungsumgebung. Verwenden Sie für neue Plattformen Accounts v2, aktivieren Sie die Entwicklerkonfiguration und fordern Sie die Funktion `Projekte` an. Bestätigen Sie die erforderliche API-Version und die Felder mit den Inhaber/innen der Vorschau: ``` POST /v2/core/accounts Stripe-Version: 2026-09-30.preview { "contact_email": "{{OWNER_EMAIL}}", "display_name": "{{TENANT_DISPLAY_NAME}}", "identity": { "country": "{{COUNTRY}}", "entity_type": "{{individual|company}}" }, "configuration": { "developer": { "capabilities": { "projects": {"requested": true} } } }, "include": ["configuration.developer", "requirements", "identity"] } ``` Die Accounts API und die Provisioning API verwenden dieselbe Vorschauversion, aber Stripe aktiviert sie separat. Bestätigen Sie, dass Stripe die erforderliche Accounts-v2-Konfiguration und die Felder für Ihre Kohorte aktiviert hat. Der Zugriff auf eine API gewährt keinen Zugriff auf die andere. Speichern Sie die zurückgegebene Konto-ID als `{{CONNECTED_ACCOUNT_ID}}` im Mandantendatensatz. Das bloße Festlegen von `contact_email` stellt nicht die Identität der Kontoinhaber/innen fest und erfüllt auch keine Verifizierungsanforderungen. Wenn Ihre Plattform bereits Accounts v1 verwendet, migrieren oder ändern Sie die Konfiguration verbundener Konten nicht allein auf Grundlage dieses Leitfadens. Bestätigen Sie den unterstützten Vorschau-Onboarding-Pfad mit den Inhaber/innen der Vorschau. ## Leiten Sie die Nutzer/innen durch das gehostete Onboarding Erstellen Sie einen Konto-Link für das Konto-Onboarding und leiten Sie die authentifizierte Nutzerin oder den authentifizierten Nutzer dann zu der entsprechenden kurzlebigen URL weiter: ``` POST /v2/core/account_links Stripe-Version: 2026-09-30.preview { "account": "{{CONNECTED_ACCOUNT_ID}}", "use_case": { "type": "account_onboarding", "account_onboarding": { "refresh_url": "{{PLATFORM_REFRESH_URL}}", "return_url": "{{PLATFORM_RETURN_URL}}", "collection_options": {"fields": "currently_due"} } } } ``` Wenn dieser abläuft, erstellen Sie einen weiteren Link. Verwenden Sie für spätere Korrekturen `account_update`: ``` POST /v2/core/account_links Stripe-Version: 2026-09-30.preview { "account": "{{CONNECTED_ACCOUNT_ID}}", "use_case": { "type": "account_update", "account_update": { "refresh_url": "{{PLATFORM_REFRESH_URL}}", "return_url": "{{PLATFORM_RETURN_URL}}" } } } ``` Authentifizieren Sie sowohl den `refresh_url`- als auch den `return_url`-Handler. Der Aktualisierungs-Handler erstellt einen neuen Konto-Link mit demselben Intent. Rufen Sie das Konto ab, nachdem der/die Nutzer/in zurückkehrt: ``` GET /v2/core/accounts/{{CONNECTED_ACCOUNT_ID}}?include=configuration.developer&include=requirements Stripe-Version: 2026-09-30.preview ``` Überprüfen Sie die Projects-Funktion der DeveloperConfig und noch ausstehende Anforderungen. Behandeln Sie die Weiterleitung des Konto-Links nicht allein als Nachweis für den Abschluss. Starten Sie die Bereitstellung erst, nachdem die Funktion `Projekte` aktiv ist und das erforderliche Onboarding abgeschlossen ist. Wenn für Ihre Kohorte Ereignisse für den Funktionsstatus aktiviert sind, behandeln Sie ein Ereignis als Aufforderung, das Konto abzurufen, und nicht als verbindliche Informationsquelle. ## Überprüfen Sie die Berechtigung für das verbundene Konto ``` GET /v2/provisioning/eligibility ``` Interpretieren Sie die Berechtigung getrennt von der Katalogverfügbarkeit: | Ergebnis | Plattformhandlung | | --- | --- | | `is_eligible=false` | Stopp. Überprüfen Sie die Mandanten-Konto-Beziehung und die aktuelle Kohortenzugehörigkeit und befolgen Sie dann die genehmigte Onboarding-Sanierung. | | `is_eligible=true` mit einem nicht leeren Array von `Anforderungen` | Behandeln Sie das Konto nicht als vollständig bereit. Leiten Sie die erforderlichen Identitäts- oder Konditionsarbeiten durch den genehmigten Onboarding-Pfad weiter und rufen Sie dann den aktuellen Status erneut ab. | | `is_eligible=true` ohne Anforderungen | Fahren Sie mit den Katalog-, Abrechnungs-, Verbindungs- und Genehmigungsprüfungen fort. | Die Kontoberechtigung, die Konto-Onboarding-Anforderungen, die Dienstverfügbarkeit und Ihre eigene Produktrichtlinie sind vier separate Hürden. Eine `wahre` Antwort zur Berechtigung macht einen nicht verfügbaren Dienst nicht nutzbar und autorisiert keinen kostenpflichtigen Schreibvorgang. ## Entdecken Sie einen bereitstellbaren Dienst Lesen Sie den Katalog des verbundenen Kontos beim Planen und erneut unmittelbar vor der Bereitstellung: ``` GET /v2/provisioning/catalog/providers?limit=100 GET /v2/provisioning/catalog/services?provider_name={{PROVIDER_NAME}}&limit=100 ``` Ein eingeschränkter Schlüssel benötigt `rak_provisioning_project_read` für beide oben genannten Aufrufe. #### Wählen Sie einen Service aus Listen Sie für jeden infrage kommenden Anbieter die Dienste auf, indem Sie exakt denselben `provider_name` dieses Anbieters und dieselbe Auswahl für Katalog und Entwicklung verwenden. Wenn die Antwort auf die Dienste ein leeres `Daten`-Array enthält, kann dieser Anbieter für diesen Plan nicht bereitgestellt werden. Erstellen Sie dafür keine Verbindungsanfrage für den Anbieter. Die API verfügt über keinen generischen Parameter für Volltext- oder Kategoriensuchen. Erstellen Sie keinen. Folgen Sie allen Seiten, erstellen Sie einen lokalen Index aus den zurückgegebenen `Daten`, wenden Sie eine deterministische Produktrichtlinie an und präsentieren Sie dann nur zulässige zurückgegebene Services für eine modellgestützte Erklärung oder ein Ranking. | Katalogfeld | Verwenden Sie | | --- | --- | | Anbieter `ID` | Senden Sie in Anfragefeldern namens `Anbieter`. | | `Name` des Anbieters | Zeigen Sie dies Nutzerinnen und Nutzern an und senden Sie es nur an Endpoints, die `provider_name` explizit akzeptieren. | | Anbieter `configuration_schema` | Überprüfen Sie die Verbindungskonfiguration, bevor Sie eine Verbindungsanfrage für den Anbieter erstellen. | | Service `service_id` | Senden Sie diesen Wert als `service_ref`, wenn Sie eine Ressource erstellen, verknüpfen oder aktualisieren. | | Service `configuration_schema` | Verwenden Sie dieses Schema, um die Konfiguration zu validieren, wenn Sie eine Ressource erstellen oder aktualisieren. | | `Verfügbarkeit` | Schließen Sie nicht verfügbare Dienste aus. | | `pricing.paid_pricing` | Zeigen Sie kostenpflichtige Preise aus diesem Feld an. Verwenden Sie nicht das veraltete Feld `pricing.paid`. | | `Art` und Komponente `parent_services` | Identifizieren Sie Pläne, bereitstellbare Elemente, Komponenten und Voraussetzungen. | | `Gültigkeitsbereich` | Entscheiden Sie über Projektplatzierung und -zuordnung. | | `Einschränkungen`, `allowed_updates` | Verhindern Sie nicht unterstützte Erstellungen und Änderungen. | | `Funktionen` des Anbieters | Aktivieren Sie optionales Verhalten nur, wenn der Anbieter dieses bewirbt. | Verwenden Sie dieselbe Katalogpartition für Kataloganfragen und alle Projekt- oder Ressourcenanfragen, die diese unterstützen. Legen Sie `development=true` nur fest, wenn die Nutzerin/der Nutzer reine Entwicklungseinträge auswählt. #### Planen Sie Abhängigkeiten vor der Verbindung oder Bereitstellung Ein Anbieter kann einen Plandienst und abhängige bereitstellbare Dienste anbieten oder Komponentendienste mit `parent_services`. Behandeln Sie erforderliche Pläne und übergeordnete Elemente als separate Ressourcen im Plan: ``` Plan prerequisite → user approves prerequisite and dependent action → create prerequisite Resource → wait for complete → refresh catalog and approval-sensitive fields → create dependent Resource ``` Wenn Informationen zu Abhängigkeiten unklar sind, halten Sie an, anstatt verschiedene Anbieter oder Dienste zu testen. Behandeln Sie reine HTTP-Statuscodes von einem Anbieter nicht als Teil Ihres Client-Vertrags. Verwenden Sie stattdessen die Status, Fehlercodes und sicheren Fehlermeldungen der Provisioning API. ## Konfigurieren Sie die Abrechnung für kostenpflichtige Dienste Rufen Sie zunächst das Profil des effektiven verbundenen Kontos ab: ``` GET /v2/provisioning/payment_profile?livemode=false ``` Legen Sie bei jedem Lesevorgang `livemode` als Abfrageparameter fest. Er wird nicht vom Modus übernommen, in dem die Zahlungsmethode erstellt wurde, und der Endpoint ignoriert den Header `Stripe-Livemode`. Senden Sie `livemode=false`, um ein Profil im Test-Modus zu lesen: Ein vorhandenes Profil im Test-Modus gibt `404` zurück, wenn Sie den Abfrageparameter weglassen oder ihn nur über den Header festlegen, sodass ein erfolgreicher Schreibvorgang so aussieht, als wäre er stillschweigend fehlgeschlagen. Ein `404 not_found` mit der Meldung „Es ist noch keine Zahlungsmethode hinterlegt“ ist der normale Ausgangszustand eines Kontos und kein Fehler. Behandeln Sie dies als „noch keine Zahlungsmethode“ und fahren Sie mit einem der Zahlungswege fort. Verwenden Sie einen der Zahlungswege, der explizit für Ihre Kohorte aktiviert wurde: | Pfad | Anfrage | | --- | --- | | Gehosteter Einzug für verbundenes Konto | Erstellen Sie eine Anfrage für eine Zahlungsmethode mit `usage_limits`; lassen Sie `payment_method_owner` und alle `source_*`-Felder weg. Leiten Sie die autorisierte Nutzerin/den autorisierten Nutzer an die zurückgegebene kurzlebige `checkout_session_url` weiter und fragen Sie dann das Zahlungsprofil mit dem passenden Abfrageparameter `livemode` ab. | | Plattformeigene Quelle | Verwenden Sie diesen Ablauf nur, wenn Stripe ihn explizit für Ihre Vorschau-Kohorte aktiviert. Bevor Sie die Schreibanfrage senden, stellen Sie sicher, dass die Kundin/der Kunde und die PaymentMethod zu demselben Quellkonto gehören. Schließen Sie `payment_method_owner: "platform"`, `source_account`, `source_customer`, `source_payment_method` und `usage_limits` in die Anfrage ein. | Für den gehosteten Einzug über das verbundene Konto senden Sie nur `usage_limits`: ``` POST /v2/provisioning/payment_method_requests { "livemode": false, "usage_limits": { "max_amount": "5000", "currency": "usd", "recurring_interval": "month" } } ``` Die Antwort gibt `checkout_session_url` und `Status` zurück. Für den Pfad der plattformeigenen Quelle senden Sie die Felder für Inhaberin/Inhaber und Quelle an denselben Endpoint: ``` POST /v2/provisioning/payment_method_requests { "livemode": false, "payment_method_owner": "platform", "source_account": "{{PLATFORM_ACCOUNT_ID}}", "source_customer": "{{PLATFORM_CUSTOMER_ID}}", "source_payment_method": "{{PAYMENT_METHOD_ID}}", "usage_limits": { "max_amount": "5000", "currency": "usd", "recurring_interval": "month" } } ``` `max_amount` verwendet die kleinste Währungseinheit und Sie senden diesen Wert als String. Die API stellt int64-Felder als Strings dar, sodass eine Zahl ohne Anführungszeichen mit `invalid_fields` fehlschlägt. Wenden Sie dieselbe Konvention auf jedes Feld für große Zahlen an. Gültige Intervalle sind `Woche`, `Monat` und `Jahr`. Verwenden Sie `POST /v2/provisioning/payment_profile/update_limit`, was den Betrag ebenfalls als String annimmt, für kontoweite Limits oder anbieterspezifische Überschreibungen. Behandeln Sie den Zahlungsmodus, die Katalogpartition und die App-Umgebung als unabhängige Einstellungen. Der Zugriff auf den Katalog `Dev` oder `Testing` garantiert nicht, dass der Anbieter keine Infrastruktur erstellt oder eine Zahlung autorisiert. Eine Vorschau-Bereitstellung ändert auch nicht den Zahlungsmodus. Behandeln Sie eine bezahlte Validierung als potenziell kostenpflichtig, es sei denn, Ihre eingeschriebene Kohorte und der Anbieter bestätigen ausdrücklich das Gegenteil. Der Abschluss der Zahlungseinrichtung genehmigt keine Anbieterverbindung, kostenpflichtige Ressource, Stufenänderung oder Ausgabenerhöhung. Fordern Sie für jede Aktion eine separate Genehmigung durch die Nutzerin/den Nutzer an. Behandeln Sie ein Provisioning-Nutzungslimit als Autorisierungslimit und nicht als Lifecycle-Richtlinie. Gehen Sie nicht davon aus, dass das Erreichen des Limits eine Ressource löscht, die Dienstverfügbarkeit aufrechterhält oder anbieterübergreifend dieselbe Benachrichtigung auslöst. Prüfen Sie die Dienst- und Anbieterverträge, halten Sie das Limit für den/die Nutzer/in sichtbar und stellen Sie eine von der Nutzerin/vom Nutzer genehmigte Möglichkeit bereit, dieses zu ändern. #### Ordnen Sie bestehende Plattform-Kundinnen und -Kunden Provisioning-Tenants zu Wenn Ihre Nutzerinnen und Nutzer auf Ihrer Plattform bereits `Kunden`-Objekte und gespeicherte Zahlungsmethoden haben, migrieren oder ersetzen Sie diese nicht. Ein/e Nutzer/in kann sowohl eine Plattform-Kundin/ein Plattform-Kunde als auch ein verbundenes Konto sein: ``` Platform user ├── Platform Customer: stores the payment method for your platform's own charges └── Connected account: owns Provisioning Projects, Provider connections, Resources, usage, and the payment profile ``` - Das Provisioning-Zahlungsprofil und nicht Ihre Plattformkundin/Ihr Plattformkunde autorisiert die Dienste des Anbieters. - Der Pfad der plattformeigenen Quelle ermöglicht es Ihnen, eine Zahlung über eine Zahlungsmethode abzuwickeln, die Sie bereits gespeichert haben, aber er ist nur verfügbar, wenn er explizit für Ihre Kohorte aktiviert wurde. - Die Provisioning API macht Ihre Plattform nicht zum Merchant of Record für Anbieterdienste und implementiert kein Connect-Transfers- oder Marketplace-Modell. Entwerfen Sie diese bei Bedarf separat mit Connect. ## Erstellen Sie ein Projektplan Erstellen Sie nach der Genehmigung ein Projekt für die Anwendungsumgebung: ``` POST /v2/provisioning/projects { "name": "{{APPLICATION_NAME}} {{ENVIRONMENT}}" } ``` Speichern Sie die Projekt-ID mit dem Anwendungsumgebungsdatensatz der Plattform. Verwenden Sie separate Vorschau- und Produktionsprojekte, wenn deren Ressourcen oder Anmeldedaten isoliert bleiben müssen. ## Einen Anbieter verbinden Listen Sie Anbieterverbindungen auf, bevor Sie eine neue Anfrage erstellen: ``` GET /v2/provisioning/provider_connections?limit=100 ``` Wenn mehrere aktive Verbindungen das Ergebnis mehrdeutig machen, zeigen Sie, wo verfügbar, sicher zurückgegebene Details zum Anbieterkonto an und halten Sie zur Überprüfung an. Wenn keine nutzbare aktive Verbindung vorhanden ist, überprüfen Sie das `configuration_schema` des Anbieters und erstellen Sie dann nach der Genehmigung eine Verbindungsanfrage für den Anbieter: ``` POST /v2/provisioning/provider_connection_requests { "provider": "{{PROVIDER_ID}}", "configuration": {}, "project": "{{PROJECT_ID}}" } ``` Verwenden Sie `{}` nur, wenn das Anbieterschema keine Pflichtfelder aufweist. Speichern Sie die zurückgegebene ID der Anbieterverbindungsanfrage, bevor Sie die Nutzer/innen weiterleiten oder zusätzliche Informationen erfassen. Bevor Sie eine Ressource bereitstellen, bestätigen Sie, dass der Anbieter über genau eine aktive Verbindung verfügt. Anfragen zum Erstellen und Verknüpfen von Ressourcen identifizieren den Anbieter, nicht eine bestimmte Anbieterverbindung. Zeigen Sie keine Verbindungsauswahl an, da die Schreib-API die ausgewählte Verbindung nicht verwenden kann. | Status der Anbieterverbindungsanfrage | Plattformhandlung | | --- | --- | | `angefordert` | Rufen Sie die Anbieterverbindungsanfrage ab, bis sie fortschreitet oder eine festgelegte Frist abläuft. | | `pending_auth` | Zeigen Sie `redirect_url` nur den authentifizierten Nutzer/innen an, speichern Sie den Status und fragen Sie ihn vom Backend ab. | | `needs_information` | Rendern Sie unterstützte `needs_information_schema`-Formen, erfassen Sie nur von Nutzer/innen bereitgestellte Werte und senden Sie dann `{ "information": {{VALIDATED_INFORMATION}} }`. Schließen Sie `confirmation_secret` nur ein, wenn der Anbieterablauf dies zurückgibt; behandeln Sie es als Geheimnis. | | `complete` | Lesen Sie die resultierende Verbindung aus `provider_connection` aus und überprüfen Sie eine eindeutige aktive Verbindung, bevor Sie fortfahren. Die Anfrage bleibt auf `vollständig`, auch nachdem diese Verbindung getrennt wurde. In diesem Fall fehlt `provider_connection`. | | `error` | Stoppen Sie und zeigen Sie nur einen sicheren Fehler an. | Behandeln Sie den Immediate-Connect-Pfad direkt in der Erstellungsantwort. Einige Anbieter schließen während der Erstellungsanfrage ab und geben `vollständig` mit einer aktiven `provider_connection` und ohne `redirect_url` zurück. Warten Sie also nicht auf eine Weiterleitung und fragen Sie keine bereits abgeschlossene Anfrage weiter ab. Ein Anbieter kann verifizierte KYC-Informationen, wie z. B. eine verifizierte E-Mail-Adresse, verlangen, auch wenn Ihr Produkt diese Informationen als optional behandelt. Überprüfen Sie das `configuration_schema` des Anbieters sowie jedes zurückgegebene `needs_information_schema` auf Pflichtfelder. Erfassen und senden Sie alle erforderlichen Informationen, einschließlich der E-Mail, falls angegeben. Wenn die Anbieterauthentifizierung eine Browser-Weiterleitung erfordert, pausieren Sie den Workflow und speichern Sie die ID der Anbieterverbindungsanfrage. Setzen Sie den Workflow nach dem Browser-Schritt mit dieser ID fort. Umgehen oder simulieren Sie die Authentifizierung nicht. Der aktuelle Ablauf akzeptiert keine Plattform-Rückruf-URL. Stripe übernimmt den Anbieterrückruf und den Token-Umtausch. Stellen Sie optionale PKCE-Felder nur bereit, wenn Stripe diese explizit für Ihren Vorschauablauf aktiviert und verlangt. ## Eine Ressource erstellen oder verknüpfen Bevor Sie die Schreibanfrage senden, überprüfen Sie Folgendes: - Das erforderliche Onboarding ist abgeschlossen. - Der Dienst ist im ausgewählten Katalog weiterhin verfügbar. - Alle vorausgesetzten Plan- oder übergeordneten Ressourcen sind abgeschlossen. - Der Anbieter verfügt über genau eine aktive Verbindung. - Die Ressourcenkonfiguration entspricht dem aktuellen Dienst-`configuration_schema`. - Für jeden kostenpflichtigen Dienst ist ein Zahlungsprofil vorhanden. - Der `Gültigkeitsbereich`, die `Einschränkungen`, die zulässigen Aktualisierungen und die Projektzuordnung der Ressource sind gültig. - Die Nutzer/innen haben den aktuellen Plan genehmigt. ``` POST /v2/provisioning/resources { "provider": "{{PROVIDER_ID}}", "service_ref": "{{SERVICE_ID}}", "project": "{{PROJECT_ID}}", "livemode": {{true|false}}, "name": "{{RESOURCE_NAME}}", "configuration": {{VALIDATED_SERVICE_CONFIGURATION}} } ``` Legen Sie `livemode` bei Erstellungs- und Verknüpfungsanfragen immer explizit fest. Wenn Sie dies weglassen, wird `wahr` als Standard von Stripe verwendet, was eine Anbieterinfrastruktur im Live-Modus erstellen und echte Gebühren verursachen kann. Setzen Sie `livemode` für die Testbereitstellung auf `falsch`. Das Ressourcenfeld `Umgebung` akzeptiert nur `Dev` oder `Prod`. Ordnen Sie Ihre Anwendungsumgebung, z. B. Vorschau oder Produktion, einem dieser Werte zu. Die Felder `Umgebung` und `livemode` sind unabhängig voneinander: `environment=dev` bedeutet nicht, dass die Ressource in einer Sandbox ausgeführt wird. Geben Sie für einen Service auf Projektebene `Projekt` an. Lassen Sie für einen Service auf Kontoebene `Projekt` weg, es sei denn, Sie müssen die Ressource mit einem Projekt verknüpfen. Das Einschließen von `Projekt` erstellt die Verknüpfung, ändert jedoch nicht den Gültigkeitsbereich der Anbieter-Ressource. Übernehmen Sie vorhandene Infrastruktur nur, wenn der Anbieter `resources:link` ausweist und die Nutzer/innen dies genehmigt haben: ``` POST /v2/provisioning/resources/link { "provider": "{{PROVIDER_ID}}", "service_ref": "{{SERVICE_ID}}", "project": "{{PROJECT_ID}}", "environment": "{{dev|prod}}", "catalog": "{{CATALOG}}", "livemode": {{true|false}} } ``` ## Asynchrone Arbeit sicher fortsetzen Eine Ressource ist nur nutzbar, wenn `status=complete` ist. | Ressourcenstatus | Plattformhandlung | | --- | --- | | `pending` | Fragen Sie `GET /v2/provisioning/resources/{id}` mit begrenztem exponentiellem Backoff und Jitter ab. | | `needs_information` | Erfassen Sie schemagültige Eingaben von Nutzer/innen, senden Sie `{ "submitted_information": {{VALIDATED_INFORMATION}} }` und setzen Sie das Polling fort. | | `complete` | Erfassen Sie die Ressource in der Anwendungsumgebung und setzen Sie den Workflow fort. | | `fehlgeschlagen` | Stoppen Sie und zeigen Sie `error_message` nur an, wenn dies sicher ist. | | `entfernt` | Behandeln Sie dies als endgültig | Fragen Sie während der Vorschau nach 1, 2, 4, 8, 16 und 30 Sekunden ab, danach alle 30 Sekunden für bis zu 15 Minuten. Fügen Sie jeder Wartezeit einen kleinen zufälligen Versatz, genannt Jitter, hinzu, damit Workflows, die gleichzeitig gestartet wurden, ihre Abfragen nicht in denselben Momenten senden. Die API definiert keine Polling-Intervalle, Webhooks oder endgültige Ratenbegrenzungen. Wenn beim Polling ein Timeout auftritt, behalten Sie die Objekt-IDs bei und setzen Sie den Status auf `requires_review`. Senden Sie die Schreibanfrage nicht automatisch erneut. ## Ressourcen-Zugangsdaten abrufen Nachdem die Ressource den Status `status=complete` erreicht hat, rufen Sie ihre aktuelle, vom Anbieter ausgestellte Zugangskonfiguration von Ihrem Backend ab: ``` POST /v2/provisioning/resources/{id}/reveal_access_configuration ``` Senden Sie keinen Anfragetext. Erteilen Sie für einen eingeschränkten Schlüssel die Berechtigung `provisioning_resource_reveal_access_configuration`. Der Endpoint gibt die neueste verfügbare Zugangskonfiguration zurück: ```json { "object": "v2.provisioning.resource_access_configuration", "created": "2026-09-21T14:00:00Z", "resource": "fres_123", "livemode": false, "configuration": { "DATABASE_URL": "postgres://USER:PASSWORD@db.example.test/DATABASE" }, "expires_at": "2026-09-22T14:00:00Z" } ``` Behandeln Sie die vollständige Antwort als Geheimschlüssel. Kopieren Sie nur die erforderlichen Konfigurationswerte in den Secret Store Ihres Bereitstellungssystems. Geben Sie die Antwort nicht an einen Browser zurück und nehmen Sie keine Konfigurationsnamen oder -werte in Logs, Analysen, Support-Tickets oder Modell-Prompts auf. Das optionale Feld `expires_at` fehlt, wenn der Anbieter keine Ablaufzeit festlegt. Das Abrufen einer Zugangskonfiguration rotiert keine Zugangsdaten und erfordert keinen Idempotenz-Schlüssel. Um Ersatz-Zugangsdaten zu erhalten, rotieren Sie zuerst die Ressource. Wenn die Rotation `complete` zurückgibt, rufen Sie die neue Zugangskonfiguration ab. Senden Sie den gleichen verifizierten Wert für `Stripe-Context`, den Sie zum Erstellen oder Abrufen der Ressource verwendet haben. Rufen Sie Zugangsdaten nur für eine Ressource ab, auf die Ihre authentifizierte Nutzerin oder Ihr authentifizierter Nutzer zugreifen darf. ## Ressourcen verwalten ### Aktualisieren Aktualisieren Sie vor einem Update den Dienst und überprüfen Sie `allowed_updates`, `Einschränkungen`, den aktuellen Katalog und die Genehmigung. ``` POST /v2/provisioning/resources/{id} { "configuration": {{VALIDATED_SERVICE_CONFIGURATION}}, "service_ref": "{{OPTIONAL_NEW_SERVICE_ID}}", "catalog": "{{CATALOG}}" } ``` Lassen Sie `service_ref` bei einem reinen Konfigurations-Update weg. Die Antwort ist ein Operationsergebnis: `ausstehend`, `abgeschlossen` oder `fehlgeschlagen`. Verlassen Sie sich nicht auf die veraltete `resource_id` in der Antwort. ### Anmeldedaten wechseln `POST /v2/provisioning/resources/{id}/rotate_credentials` gibt `ausstehend`, `abgeschlossen` oder `fehlgeschlagen` zurück. - `abgeschlossen`: Erfassen Sie die Rotation in der Ressource und entwerten Sie alle Anmeldeinformationen, die der Anbieter vor der Rotation ausgestellt hat. - `fehlgeschlagen`: Stoppen Sie den Workflow und belassen Sie die Ressource unverändert. - `ausstehend`: Senden Sie die Rotationsanfrage nicht erneut. Setzen Sie den Status auf `requires_review`. Die Vorschau-API bietet keine dauerhafte Möglichkeit, die Rotationsoperation abzurufen, und das spätere Lesen der Ressource bestätigt nicht, dass die Rotation abgeschlossen wurde. ### Entfernen, Verknüpfung aufheben und Verbindung trennen Fordern Sie für jede Aktion eine separate Genehmigung an. | Aktion | Endpoint | Auswirkungen | | --- | --- | --- | | Bereitstellung der Infrastruktur aufheben | `POST /v2/provisioning/resources/{id}/remove` | Fordert das Entfernen der Anbieterinfrastruktur an. | | Verwaltung einer Ressource beenden | `POST /v2/provisioning/resources/{id}/unlink` | Entfernt die Provisionierungsverknüpfung; die Anbieterinfrastruktur wird dadurch nicht gelöscht. | | Anbieterverbindung vergessen | `POST /v2/provisioning/provider_connections/{id}/unlink` | Entfernt die gespeicherte Verbindung von Stripe. Ressourcen werden nicht entfernt und der Widerruf von Tokens aufseiten des Anbieters wird nicht garantiert. | Gehen Sie nach dem Entfernen oder Trennen einer Ressource nicht davon aus, dass der Anbieter zuvor ausgestellte Anmeldedaten ungültig gemacht hat. Bestätigen Sie deren Status beim Anbieter. ## Umgang mit Fehlern Verwenden Sie den `error.code` der Provisioning API, den zurückgegebenen Status und sichere Nachrichten zur Fehlerbehandlung. Verzweigen Sie nicht auf Basis von angenommenen rohen HTTP-Status des Anbieters. | Fehlercode | Plattformhandlung | | --- | --- | | `payment_method_required` | Schließen Sie die Zahlungseinrichtung ab, holen Sie die Genehmigung ein und versuchen Sie es dann gezielt erneut. | | `payment_method_and_customer_required` | Geben Sie für einen aktivierten Plattform-Quellfluss den entsprechenden Quellkunden/die entsprechende Quellkundin und die entsprechende Zahlungsmethode an. | | `payment_method_owner_required` | Legen Sie für einen aktivierten Plattform-Quellfluss `payment_method_owner=platform` fest. | | `unsupported_payment_method_owner` | Stopp; verwenden Sie nur einen aktuell aktivierten Inhabermodus. | | `connect_relationship_required` | Überprüfen Sie die Beziehung zwischen Plattform und verbundenem Konto sowie den Wert für `Stripe-Context`. | | `provider_reauth_required` | Erstellen Sie eine neue Anbieterverbindungsanfrage und bitten Sie die Nutzer/innen, die Verbindung erneut herzustellen. | | `invalid_resource_configuration` | Aktualisieren Sie das Schema und erfassen Sie die korrigierten Nutzereingaben. | | `resource_count_constraint_exceeded` | Erklären Sie die Einschränkung und bieten Sie eine zulässige Aktualisierung, Zuordnung oder eine bestehende Ressource an. | | `resource_not_complete` | Rufen Sie die Ressource ab und verfolgen Sie ihren aktuellen Status. Fragen Sie nur ab, während der Status `pending` lautet, übermitteln Sie erforderliche Informationen, wenn er `needs_information` lautet, und stoppen Sie, wenn er `errored` oder `removed` lautet. Rufen Sie die Zugangskonfiguration ab, nachdem die Ressource den Status `complete` erreicht hat. | | `resource_access_configuration_unavailable` | Stoppen Sie. Verknüpfen Sie die Ressource neu, rotieren Sie sie oder befolgen Sie die Anweisungen des Anbieters in den Statusdetails. | | `resource_access_configuration_expired` | Rotieren Sie die Zugangsdaten der Ressource. Wenn die Rotation `complete` zurückgibt, rufen Sie den Ersatz ab. Wenn sie `pending` zurückgibt, setzen Sie den Workflow-Status auf `requires_review`. | | Fehlende Berechtigung HTTP `403` | Verwenden Sie einen Schlüssel mit der Berechtigung `provisioning_resource_reveal_access_configuration`. | | Sonstiger HTTP-`403`-Fehler | Überprüfen Sie die Anmeldung zur privaten Vorschau, das Konto für `Stripe-Context` und den Projektumfang der Ressource. Fügen Sie keine Berechtigungen hinzu, es sei denn, der Fehler weist auf eine fehlende Berechtigung hin. | | `provider_failure` | Zeigen Sie eine sichere Nachricht an. Identifizieren Sie nach Möglichkeit eine zurückgegebene Voraussetzung; versuchen Sie es nur nach Genehmigung und nur dann erneut, wenn es sicher ist. | | `api_error` oder unbekannter Code | Stoppen Sie, zeichnen Sie sichere Diagnosen auf, rufen Sie bekannte Objekte ab, markieren Sie `requires_review` und führen Sie den Schreibvorgang nicht automatisch erneut aus. | | `not_found` | Überprüfen Sie die Objekt-ID und `Stripe-Context`; prüfen Sie kein anderes Konto. | | `rate_limited` oder HTTP `429` | Wenden Sie ein Backoff mit exponentieller Verzögerung und Jitter an und respektieren Sie ein zurückgegebenes `Retry-After`, falls vorhanden. Verkürzen Sie nicht die Polling-Intervalle, verteilen Sie Wiederholungsversuche nicht auf verschiedene Ressourcen und umgehen Sie die Begrenzung nicht durch das Hinzufügen paralleler Aufrufer. | Speichern Sie bei einem `api_error`, nicht verfügbaren Anfrage-Logs oder einem unbekannten Schreibergebnis den Endpoint, die Aktion, die nicht geheime Anfrage-ID, die Objekt-IDs, den HTTP-Status, den Fehlercode und die Fehlernachricht sowie den aktuellen Workflow-Status. Wenn `request_log_url` fehlt, nicht verfügbar oder nicht hilfreich ist, zeichnen Sie dieses Ergebnis als Beweis auf. Bitten Sie die Nutzer/innen nicht, die URL wiederholt erneut aufzurufen. Setzen Sie den Workflow-Status auf `requires_review`, nachdem eine Schreibanfrage eine Zeitüberschreitung aufweist oder ein unbekanntes Ergebnis zurückgibt. Rufen Sie im selben Kontext des verbundenen Kontos die bekannten Anbieterverbindungsanfragen und Ressourcen ab. Gleichen Sie den beobachteten Status mit einer autorisierten Nutzerin oder einem autorisierten Nutzer ab und holen Sie deren Genehmigung ein, bevor Sie eine weitere Schreibanfrage senden. Führen Sie die ursprüngliche Anfrage nicht automatisch erneut aus. ## Ihre Integration testen Testen Sie vor der Bereitstellung mit Konten und Diensten, die Ihre Kohorte ausdrücklich registriert: 1. Überprüfen Sie die Autorisierung von der Nutzerin oder dem Nutzer über den Mandanten bis zum verbundenen Konto. Bestätigen Sie, dass nicht vertrauenswürdige Konto-IDs den Kontext nicht ändern können. 2. Schließen Sie das Onboarding für das verbundene Konto ab und bestätigen Sie, dass das Konto sowohl mit leeren als auch mit nicht leeren Anforderungen bereit ist. 3. Testen Sie Paginierung, die Konsistenz von Katalog- und Entwicklungspartitionen, leere Servicelisten, Verfügbarkeit, Preisgestaltung, Umfang, Einschränkungen und Schema-Validierung. 4. Testen Sie Plan- und bereitstellbare Abhängigkeiten sowie Abhängigkeiten zwischen Komponente und übergeordnetem Element, ohne bei rohen `422`-Antworten des Anbieters zu verzweigen. 5. Testen Sie die sofortige Anbieterverbindung, die Browser-Weiterleitung und `needs_information`. Überprüfen Sie die Workflow-Wiederherstellung nach einem Browser- oder Sitzungsverlust. 6. Testen Sie eine kostenlose Ressource über `ausstehend`, `needs_information` und den Abschluss. 7. Testen Sie das kostenpflichtige Provisioning nur dann, wenn die Kohorte dies bestätigt, und zwar mit einem ausdrücklich niedrigen Limit und einer neuen Genehmigung. 8. Testen Sie die Aktualisierung, die erneute Authentifizierung sowie das Entfernen im Gegensatz zum Trennen von Ressourcen separat. 9. Testen Sie den Abruf von Zugangsdaten für autorisierte Ressourcen. Stellen Sie sicher, dass unvollständige, nicht verfügbare, abgelaufene, konto- und projektübergreifende Ressourcen keine Zugangsdaten weitergeben. 10. Testen Sie die synchrone Rotation von Zugangsdaten, stellen Sie sicher, dass der Abruf den bestätigten Ersatz erst nach Abschluss der Rotation zurückgibt, und verlangen Sie, dass ausstehende Rotationen geprüft werden. 11. Testen Sie `provider_failure`, `api_error`, Polling-Zeitüberschreitungen, unbekannte Schreibvorgänge und nicht verfügbare Anfrage-Log-Links. ## Einschränkungen der Vorschau - Zugangskonfigurationen werden einzeln pro Ressource abgerufen. Die Vorschau bietet keinen Massenabruf von Zugangsdaten. - Es gibt keinen dokumentierten Webhook-Support für das Provisioning. Verwenden Sie daher begrenztes Polling. - Es gibt keinen dokumentierten Vertrag zur Aufrufer-Idempotenz oder Korrelation für Schreibvorgänge. - Es gibt kein dokumentiertes Client-Polling-Intervall und keine endgültige Richtlinie zur Begrenzung. Einige Anbieter wenden strenge Begrenzungen an; ein Aufrufer, der Anfragen über viele Ressourcen oder Projekte verteilt, kann diese Begrenzung selbst bei moderatem Volumen pro Nutzer/in erreichen. Wenden Sie Backoffs daher zentral anstatt pro Workflow an. - Upstream-Fehler des Anbieters sind keine stabile Client-Schnittstelle. Verwenden Sie daher die Codes der Provisioning API und sichere Nachrichten. - Eine ausstehende Rotation von Anmeldedaten hat keinen dauerhaften Flow zum Abrufen von Vorgängen. - Die kostenpflichtige Testbereitstellung und plattformeigene Zahlungsquellen hängen von der Kohorte ab. - Vorschau-Felder und Enums können sich ändern, vermeiden Sie daher veraltete Felder, wenn ein aktueller Ersatz verfügbar ist. ## See also - [Stripe Projects-CLI](https://docs.stripe.com/projects.md) - [Verfügbare Anbieter](https://docs.stripe.com/projects.md#available-providers) - [Anmeldung als Anbieter für Stripe Projects](https://docs.stripe.com/projects/provider-intake.md) - [Stripe Connect](https://docs.stripe.com/connect.md) - [Accounts v2](https://docs.stripe.com/connect/accounts-v2.md)