BAUEN MIT SHAREAI
Geben Sie Kunden eine klare Wahl über die Nutzung von KI, Ihre optionale Gebühr und jeden Kauf. Erstellen Sie eine Zahlungsreise, die sie verstehen und kontrollieren können.
Die Erfahrung, die Sie gestalten werden
Mit ShareAI bezahlenKlarer Zugriff. Akzeptierte Bedingungen. Bestätigte Käufe.
IHRE IMPLEMENTIERUNG
Halten Sie Autorisierung, akzeptierte Bedingungen und bestätigte Zahlungen sowohl in Ihrem Produkt als auch in Ihrer Implementierung explizit.
Der Kunde versteht, ob er sich verbindet, KI nutzt oder einen Kauf genehmigt.
Das Token und die Operation verwenden das vorgesehene Konto und den Umfang.
Veröffentlichen Sie verständliche Angebote und verfolgen Sie die Version, die jeder Kunde akzeptiert hat.
Neue Bedingungen verschieben einen bestehenden Kunden nicht stillschweigend.
Erstellen Sie einen vorgesehenen Kauf, überprüfen Sie dessen bezahlten Status und erfüllen Sie ihn anschließend.
Wiederholungen, Stornierungen, abgelehnte Checkouts und Limits werden behandelt.
NEHMEN SIE ES IN IHREN EDITOR
Kopieren Sie die vollständige Anleitung mit dem Implementierungsziel, den erforderlichen Eingaben und den Akzeptanzprüfungen. Halten Sie Codebeispiele, Tabellen und Dokumentationslinks zusammen.
Bereit für Ihr Projekt, im benötigten Format.
Aktualisiert
Sie werden zwischen dem Verbinden eines Kontos, dem Bezahlen für die Nutzung von KI und der Bestätigung eines Produktkaufs unterscheiden.
Wo Sie arbeiten werden Ihr Produkt → Zahlungserlebnis
Pay with ShareAI ermöglicht es einem Kunden, sein ausgewähltes ShareAI Konto in Ihrer Anwendung zu verwenden. Es gibt zwei unterschiedliche Abrechnungsabläufe: vom Kunden finanzierte KI-Anfragen unter einer akzeptierten Autorisierung und einen Produktkauf, den der Kunde beim Checkout bestätigt. Optionales Builder Markup ist eine zusätzliche Vereinbarung zur KI-Nutzung.
| Kundenaktion | Was passiert | Erforderlicher Zugriff |
|---|---|---|
| Eine Wallet verbinden | Erstellt eine Autorisierung für das ausgewählte Konto und die akzeptierten Bedingungen. Durch Klicken auf Verbinden wird kein Produkt gekauft. | openid plus die Funktionen, die Ihre App verwendet. |
| Senden Sie eine KI-Anfrage | Verwendet die berechtigten KI-Guthaben des autorisierten Kontos und die akzeptierten Nutzungsbedingungen. | Anwendbarer Inferenzzugriff; monetization_gateway für akzeptierte Builder Markup-Bedingungen. |
| Bestätigen Sie einen Produktkauf | Belastet den jeweiligen Kauf erst nach autorisierter Bestätigung. | payments und einer erfolgreichen Zahlungsanforderung. |
JamZY’s Terminbeispiel demonstriert die KI-Nutzungsroute. Es enthält keinen Händler-Checkout, fordert keinen Zahlungsumfang an und behauptet nicht, dass das Verbinden ein Abonnement kauft. Verwenden Sie die verbleibenden Kapitel, wenn Sie diese separate Erfahrung hinzufügen.
Ihr Button und Produkttext geben an, ob der Kunde verbindet, KI verwendet oder einen Kauf bestätigt.
Sie erhalten die Erlaubnis vom vorgesehenen zahlenden Konto, bevor eine Operation es verwendet.
Wo Sie arbeiten werden Konsole → Anwendungsfälle → Kundenauthorisierung
payments für den Produkt-Checkout, inference für KI zu Netzwerkkosten und monetization_gateway für ein genehmigtes KI-Markup. Fordern Sie nur die Funktionen an, die die Anwendung tatsächlich verwendet.Eine Client-ID identifiziert die Plattform. Ein Zugriffstoken repräsentiert die akzeptierte Kundenauthorisierung. Eine Vertragsversion zeichnet die Abrechnungsbedingungen auf. Keines davon allein beweist, dass eine bestimmte Produktzahlung bestätigt wurde.
Das Token gehört dem vorgesehenen Kunden und enthält die Berechtigungen für die Operation, die Sie ausführen möchten.
Sie veröffentlichen klare Nutzungsbedingungen, die der Kunde überprüfen und akzeptieren kann.
Wo Sie arbeiten werden Anwendung → Abonnements
Erstellen Sie in Abonnements klar benannte Angebote und erklären Sie die zusätzliche KI-Gebühr. Die Abonnement-ID wird generiert, ist schreibgeschützt und auf Ihre Anwendung beschränkt. Diese Angebote werden über die Plattform-Clients der App hinweg geteilt, sodass Sie kein separates kommerzielles Angebot für Web und Android pflegen.
surcharge für dieses Angebot fest.Verwenden Sie Estimate, um Netzwerkkosten, Zuschläge und Builder-Einnahmen für das gewählte Modell zu vergleichen. Veröffentlichen Sie einen überprüften Entwurf als nächste Vertragsversion. Kunden akzeptieren diese Version während der Autorisierung; ein veröffentlichtes Angebot ist nicht dasselbe wie eine akzeptierte Kundenvereinbarung.
Wenn Sie nur das Produkt payments benötigen, verwenden Sie den verfügbaren kostenlosen Zahlungszugriffsvertragsablauf, anstatt ein Builder Markup zu erfinden. Feste Abonnementpreise und Intervalle werden vom aktuellen Nutzungsangebot-Editor nicht konfiguriert; interpretieren Sie ein KI-Angebot nicht als automatische wiederkehrende Abrechnung.
Ihr Angebot beschreibt genau, was zu den AI-Kosten hinzugefügt wird. Die kundenseitige Zustimmung zeigt dieselben veröffentlichten Bedingungen.
Sie führen einen neuen Vertrag ein und behalten den Überblick über die Bedingungen, die jedes Konto akzeptiert hat.
Wo Sie arbeiten werden Abonnements → Verträge
Bereiten Sie Änderungen im nächsten Vertragsentwurf vor. Bestehende Autorisierungen behalten ihr akzeptiertes Abonnement und ihre Version, bis der Kunde einen Ersatz akzeptiert. Vergleichen Sie Kontozahlen und Verteilungen in der Abonnementübersicht, anstatt davon auszugehen, dass jedes Konto die neueste Version verwendet.
Informieren Sie Kunden über Änderungen und führen Sie sie durch den Zustimmungsprozess, um eine neue Version zu akzeptieren, wenn erforderlich. Ein aktualisiertes Token kann keine Zustimmung erzwingen. Das Beibehalten akzeptierter Verträge ist der Standardübergang. Die Entscheidung, eine erneute Zustimmung vor weiteren Aktionen zu verlangen, unterbricht absichtlich den bestehenden Zugriff, bis der Kunde die neuen Bedingungen genehmigt; überprüfen Sie diese Auswirkungen vor der Veröffentlichung. Jede erlaubte Reduzierung muss den Regeln des akzeptierten Vertrags folgen; eine Gebührenerhöhung erfordert die Zustimmung des Kunden.
Halten Sie die Anwendungsebene und die Identitätsgrenze getrennt. Plattform-spezifische Kundenkennungen bleiben auf ihren Client-Kontext beschränkt, auch wenn die kommerzielle Übersicht die gesamte Anwendung aggregiert.
Sie können identifizieren, welchen Vertrag jedes Konto akzeptiert hat, und erklären, wie es zum nächsten wechseln kann.
Sie erstellen einen beabsichtigten Kauf, erhalten eine Bestätigung und verifizieren die Zahlung vor der Lieferung.
Wo Sie arbeiten werden Ihr Backend → ShareAI Checkout → Zahlungsüberprüfung
Dieses Kapitel erweitert das Terminbeispiel um einen separaten Produktkauf. Führen Sie es nur aus, nachdem Sie Zahlungen aktiviert und ein Kundentoken mit diesem Umfang erhalten haben. Halten Sie den Bestell- und Zahlungsstatus in Ihrem Backend.
# Real payment request: use scoped test access and an intentional amount.
curl --fail-with-body 'https://api.shareai.now/api/v1/console/builder/payments' \
-H "Authorization: Bearer $SHAREAI_ACCESS_TOKEN" \
-H 'Content-Type: application/json' \
-H 'Idempotency-Key: YOUR_UNIQUE_ORDER_REFERENCE' \
--data '{"title":"JamZY appointment preparation pack","amount":"1.00"}'curl --fail-with-body --get \
'https://api.shareai.now/api/v1/console/builder/payments' \
-H "Authorization: Bearer $SHAREAI_ACCESS_TOKEN" \
--data-urlencode "id=$SHAREAI_PAYMENT_ID"| Zahlungsstatus | Was Ihr Produkt tun sollte |
|---|---|
| ausstehend | Zeigen Sie an, dass die Kundenbestätigung noch erforderlich ist. Noch nicht erfüllen. |
| bezahlt, | Überprüfen Sie die Bestellung auf Ihrem Server und erfüllen Sie sie dann einmal. |
| abgelehnt | Respektieren Sie die Entscheidung; lassen Sie den Kunden entscheiden, ob er einen weiteren Kauf versuchen möchte. |
| abgelaufen | Erstellen Sie eine neue Anfrage mit einem neuen Idempotenzschlüssel, wenn der Kunde einen erneuten Versuch wünscht. |
Verwenden Sie nur eine Checkout-URL, die von der vertrauenswürdigen API zurückgegeben wird, und validieren Sie sie gegen die zulässige Zielrichtlinie Ihrer Integration. Eine Rückmeldung über den Erfolg der Rückkehr zur App ist kein Zahlungsnachweis. Der Zahler kann nicht von seinem eigenen Builder-Konto aus einkaufen.
Wenn Sie einen bestehenden Festpreis-Abonnementvertrag unterstützen, kann die Zahlungs-API dessen akzeptierte Bedingungen für einen ausdrücklich bestätigten Zeitraum verwenden. Senden Sie keinen erfundenen wiederkehrenden Preis und belasten Sie keinen neuen Zeitraum stillschweigend. JamZY’s herunterladbares Terminbeispiel implementiert diese Erweiterung nicht.
Keine Bestellung wird geliefert, bis Ihr Backend die Zahlung verifiziert hat, und die Wiederholung des Bestätigungsablaufs kann dieselbe Bestellung nicht zweimal liefern oder belasten.
Sie werden Kreditlimits und Trennungen ohne doppelte Belastungen oder unerwartete Kontoänderungen handhaben.
Wo Sie arbeiten werden Ihre Anwendung → Abrechnungswiederherstellung
AI-Nutzung und Produktkäufe haben unterschiedliche Regeln für berechtigte Guthaben. Ein Konto kann AI-berechtigte Guthaben haben, die nicht für ein Produkt verwendet werden können. Behandeln Sie unzureichende Mittel und anwendungsspezifische Ausgabelimits mithilfe des API-Fehlers und des Abrechnungsziels des Kunden.
Zeigen Sie dem Kunden das gewählte Zahlungskonto, die fehlgeschlagene Aktion und eine Möglichkeit, Guthaben oder Limits zu verwalten. Der Kunde kontrolliert seine eigene Obergrenze; der App-Besitzer kann sie nicht erhöhen. Wechseln Sie nicht stillschweigend von einem Organisationskonto zu einem persönlichen Konto, um eine Belastung erfolgreich zu machen.
Eine Trennung sollte die entsprechende Autorisierung widerrufen und die lokale Sitzung löschen. Sie stoppt zukünftige autorisierte Anfragen; sie macht jedoch keinen bereits bestätigten Kauf rückgängig oder storniert automatisch eine separate bezahlte Verpflichtung. Fehler beim Aktualisieren, Widerruf der Berechtigung und Ablauf der Zahlung erfordern unterschiedliche Wiederherstellungsnachrichten.
Fehler bei unzureichendem Guthaben und Limits lassen den Kunden informiert und in Kontrolle, ohne versehentliche doppelte Bestellungen oder Zahlerwechsel.
Sie werden den erfolgreichen Pfad und dessen Fehlerfälle testen, bevor Sie die Plattform in die Veröffentlichung aufnehmen.
Wo Sie arbeiten werden OAuth-Einstellungen → Verifizierung
Verwenden Sie die anwendungsweite Tester-Liste und ein berechtigtes Zahlungskonto, das sich vom Builder unterscheidet. Es gibt höchstens fünf Testerplätze, einschließlich ausstehender Einladungen. Führen Sie eine vollständige Verifizierung von Endpunkt und Umfang für jede Plattform durch, die in die Veröffentlichung aufgenommen wird.
inference oder monetization_gateway und den erforderlichen erfolgreichen API-Aufruf für Zahlungen für payments. Eine Zahlungsanfrage kann ausstehend sein, ohne dass eine Belastung erfolgt; ein vollständiger Checkout-Test überprüft zusätzlich die explizite Bestätigung und die Zahlung.Ihre Integration unterscheidet akzeptierten Zugriff, akzeptierte Bedingungen, angeforderte Zahlung und bestätigte Zahlung und behandelt den Fehlerpfad für jeden Fall.
Wählen Sie das persönliche oder Organisationskonto aus, das die Programmanmeldung besitzen wird, bevor Sie sich bewerben. Organisationen können eine Bewerbung vor der Verifizierung einreichen, aber die Genehmigung durch das Personal allein aktiviert den Zugriff nicht. Schließen Sie die Verifizierung der Organisations-E-Mail und der Unternehmensdaten aus der Onboarding-Checkliste in der Konsole ab. Eine genehmigte Organisation bleibt "Ausstehende Verifizierung", bis beide Prüfungen abgeschlossen sind. Builder, Anbieter- und Creator-Programme folgen dieser Regel.
Anzeigen von Monetization Gateway Preisgestaltung · Erkunden Sie ShareAI for Startups · Scopes und Berechtigungen
Ihre öffentlichen Allgemeinen Geschäftsbedingungen, Datenschutzrichtlinien und Löschanweisungen müssen mit der Anwendung übereinstimmen und ohne Anmeldung erreichbar bleiben. Die Programmannahme ShareAI, die Genehmigung Monetization Gateway, die OAuth-Berechtigung des Kunden und der akzeptierte Abrechnungsvertrag sind separate Entscheidungen. Eine Aktualisierung kann keine Berechtigungen hinzufügen oder neue kommerzielle Bedingungen akzeptieren.
Der Legacy-Scope surcharge bleibt für bestehende Integrationen akzeptiert. Neue Beispiele verwenden monetization_gateway. Behalten Sie bestehende Wire-Felder wie surcharge_bps und surcharge_percentage unverändert bei.
Anzeigen von Monetization Gateway Preisgestaltung · Erkunden Sie ShareAI for Startups · Scopes und Berechtigungen
Standardgebühren 5% des Builder-Zuschlags. Für €2.00 der KI-Netzwerkkosten und einen 10%-Zuschlag zahlt der Kunde €2.20. ShareAI erhält €0.01 des €0.20-Zuschlags; das Builder hat €0.19 vor Event Ingestion.
Die ersten 1,000 abgeschlossenen Produktionsanfragen Monetization Gateway sind jeden Kalendermonat (UTC) kostenlos und werden über das Builder-Konto geteilt. Zusätzliche Anfragen kosten €0.04 pro 1,000 vor anwendbaren Rabatten. Eine abgeschlossene Anfrage erzeugt ein Ereignis.
Pay with ShareAI allein, inference-Zugriff ausschließlich, gewöhnliche Konto-API-Schlüssel und Staging- oder Testverkehr verursachen keine Monetization Gateway-Event-Ingestion.
ShareAI for Startups bietet ein gemeinsames monatliches Budget für tatsächliche ShareAI-Gebühren auf einer genehmigten Anwendung. Die aktuellen Launch-, Growth- und Momentum-Stufen listen €1,000, €5,000 und €10,000 pro Monat. Dasselbe Budget deckt die prozentuale Gebühr von ShareAI auf Builder-Markup und abrechenbare Event-Ingestion zusammen ab. Es ist kein Brutto-Markup-Budget, kein separates Freievent-Kontingent oder kostenlose KI-inference. Die ersten 1,000 freien Events des Kontos verbrauchen es nicht.
Verbleibende Event-Ingestion-Gebühren werden aus den neuen Einnahmen des Antrags Builder bezahlt, dann aus verfügbaren Builder KI-Einnahmen und uneingeschränkten KI-Guthaben. Kunden-KI-Gebühren und Produkt payments bleiben getrennt.
ShareAI kann anwendungsspezifische Gebühren oder Gebührenerleichterungen für einen festen Zeitraum oder bis zur Änderung genehmigen. Überprüfen Sie die aktuellen Preise und Sonderprogramme der Anwendung in der Konsole auf genehmigte Bedingungen, Gültigkeit und verbrauchtes Budget. Eine Stufenänderung oder Preisüberschreibung setzt die monatliche Nutzung der Anwendung nicht zurück.
Launch hält "Log in with ShareAI" optional. Growth und Momentum erfordern es; Momentum erfordert außerdem das offizielle ShareAI for Startups-Abzeichen im Anwendungsfooter. ShareAI überprüft das Abzeichen wöchentlich. Bestätigte Versuche, Anforderungen zu umgehen, können zu einer Herabstufung, Entfernung aus dem Startup-Programm oder einem Ausschluss vom Marktplatz gemäß den akzeptierten Programmrichtlinien führen.
Unternehmenskonditionen werden vom ShareAI-Team für das Builder-Konto konfiguriert, nachdem ein personalisiertes Angebot vereinbart wurde. Der zugewiesene Prozentsatz und die Ereignisrate gelten für zukünftige Anfragen.
Anzeigen von Monetization Gateway Preisgestaltung · Erkunden Sie ShareAI for Startups · Scopes und Berechtigungen