{
  "video_id": "KLSuFPj2ld0",
  "channel_slug": "aidotengineer",
  "channel_handle": "aidotengineer",
  "title": "Building safe Payment Infrastructure for the autonomous economy — Steve Kaliski, Stripe",
  "duration_seconds": 1126.0,
  "url": "https://www.youtube.com/watch?v=KLSuFPj2ld0",
  "upload_date": "",
  "transcript": "Ich möchte mich einfach bei allen bedanken, die\nhier sind.\nÄhm, ich bin von Stripe und heute werde ich darüber\nsprechen, wie man eine sichere Zahlungsinfrastruktur\nfür die autonome\nWirtschaft aufbaut, oder wie wir Robotern ermöglichen können,\nGeld auszugeben, und wie Unternehmen\nGeld von Robotern erhalten können.   Zu mir selbst:\nIch bin leitender\nSoftwareentwickler bei Stripe.  Meine\nersten vier Jahre habe ich als Leiter unseres\nAusgabeteams verbracht. Unser Produkt ermöglicht es\nEntwicklern, physische und virtuelle\nKreditkarten zu erstellen, die ursprünglich\nfür Menschen und zunehmend auch für Roboter bestimmt waren.\nIn den letzten zwei Jahren habe\nich erforscht, wie man Roboter\nGeld ausgeben lassen kann und wie Stripe-Unternehmen sich\nan diese neue Art von Käufer anpassen können.\nUnd wenn ich nur noch eines mitnehmen möchte, dann die Tatsache, dass Entdeckung und Erkundung vom Nichtdeterminismus profitieren, falls Sie\nfür den Rest der Präsentation nicht mehr zuhören.\nDas Erstaunliche\nan LLMs ist also, dass riesige\nInformationskonzerne, die Informationen der Welt,\nCode,\nProdukte oder Unternehmen für Sie vorhersagen und empfehlen können.\nAber Anmeldeinformationen, Zahlungen und der Bezahlvorgang\nerfordern Determinismus.  Man sollte also nicht nur\ndavon profitieren, sondern es auch benötigen.  Die\nTrennung zwischen der Frage, wie man\nDinge findet oder was man tun soll, und der Frage, wie man eine\nTransaktion durchführt,\nist also gewissermaßen der entscheidende Unterschied.\nWir werden also über\nAgenten als Wirtschaftsakteure sprechen, über all die negativen\nDinge, die passieren können, über\ndie Lösungen, an denen Stripe und unsere\nPartner gemeinsam gearbeitet haben, um\ndiese zu beheben, und dann ein wenig darüber, was als\nNächstes ansteht.   Eine\nweitere Schlussfolgerung wäre also, dass Agenten\nbereits wirtschaftliche Akteure sind, richtig?  Sie\nhaben ihre eigene Währung und ihre eigenen Token.\nWenn Sie also Cloud Code, Codex oder eine\nandere Art von Anwendung nutzen, geben Sie im\nEndeffekt Geld aus, richtig?  Es könnte\nüber Ihr Abonnement abgewickelt\noder aus den\nein- und ausgehenden Token\nin Dollar umgerechnet werden, aber im Grunde genommen\nlassen wir sie ja bereits ausgeben, oder?\nNicht etwa mit irgendeinem Unternehmen, sondern mit dem LM-\nAnbieter, mit dem sie zusammenarbeiten.\nUnsere Hauptfrage ist also, wie wir andere Währungen, andere Ausgabenmuster, andere Zahlungsmethoden und andere Geschäftsinteraktionen ermöglichen können\n.  Also, ähm, wir werden das wohl ziemlich schnell durchgehen,\ndenn wir haben\nheute ja nur über Agenten gesprochen, nehme ich an.  Also,\nAgenten produzieren Texte.  Manchmal müssen sie\nDaten lesen oder schreiben oder mit\nDritten interagieren.  Sie tun dies mithilfe von Werkzeugen,\nund manchmal kosten diese Werkzeuge Geld.\nWie können wir dies also sicher aktivieren?  Ähm,\nnochmal, das wissen wir alle, aber äh, vereinfacht gesagt\n, ruft ein Agent einfach LM an und\nruft Tools auf.  Sie geben beide aus\n.  Ähm, und die Tools, über die\nwir insbesondere sprechen werden, sind Suche,\nZugangsdatenverwaltung und Zahlung.\nEs ist der Zauber, aber es birgt auch Risiken.\nAlso, äh, was sind die Hauptprobleme?  Ähm, ich\nkann auch im falschen Laden einkaufen.\nIch kann das Falsche kaufen.  Ich kann\nden falschen Betrag ausgeben.  Ich kann die falschen\nAnmeldeinformationen verwenden.\nDer grundlegende Ansatz ist also sozusagen der\noffene Klassenstil.\nLassen wir den Roboter einfach einen Menschen bedienen. Nun ja,\nhoffentlich nicht einen\nMenschen bedienen, aber was\nAusrutschen angeht, hoffentlich passiert das nicht\n.  Der Roboter soll\nden Browser einfach wie ein Mensch bedienen.  Ähm\n, also falscher Ort.  Zunächst einmal: Wie stellt\nein Agent sicher, dass er sich am richtigen Ort\noder in der richtigen Domäne befindet?  Ähm, woher soll ich das wissen?\nDie Website sieht vielleicht\namazon.com sehr ähnlich, ist aber eben\namazon.  Was auch immer und und ist eine Fälschung\n.  Ähm, das Falsche.  Man könnte sich auf\neiner Website vergnügen und nach einem\nlila T-Shirt suchen, und man könnte vielleicht,\nweniger besorgniserregend, ein oranges\nT-Shirt kaufen, aber man könnte auch, wissen Sie,\netwas kaufen, das 10 Mal so\nteuer ist.\nDer falsche Betrag.  Ähm, wissen Sie, wie wir alle\nwissen,\nzumindest ich habe\nhier ganz andere Preise gesehen als zu Hause.\nDie Preise können schwanken.  Es gibt\nFehlberechnungen, unterschiedliche Währungen,\nSteuern und so weiter.  Beispielsweise entspricht die Zahl, die\nIhr Roboter von der Seite extrahiert, möglicherweise\nnicht dem Betrag, den\nSie tatsächlich ausgeben möchten.\nUnd natürlich die falschen Zugangsdaten.\nSie könnten Ihre Kreditkartendaten einkleben, es\nkönnte aber auch am falschen Ort landen.  Ähm, aber\nwissen Sie, es gibt ja auch andere\nZahlungsmethoden, die\nfür einen Agenten schwer oder gar unmöglich zu\nvermitteln sind.  Wir wollen also\nalle vier Probleme lösen können.  Und nochmal: Die\ngrundlegende Vorgehensweise, nur die Kartennummer zu nehmen, ist\nschlecht.  Das Surfen auf einer Website kann umständlich sein, das\nAusfüllen von Formularen, das Klicken auf „Bezahlen“ – alles geht\nlangsam und die Ergebnisse sind schwer zu erkennen.\nUnd wissen Sie, das beschränkt sich nicht nur auf\nZahlungen, richtig?  Das ist genauso wie beim\nBetrieb jeder anderen Webanwendung oder bei allem, was\nein finanzielles Risiko birgt.  Und genau deshalb\ngibt es Managed Service Provider (MSPs) und APIs.  Um es mit den Worten von\nStripe zu sagen: Das Dashboard auf der linken Seite\nist für Menschen gedacht, während\nRoboter auf der rechten Seite eher Code bevorzugen.\nDer ideale Ansatz wäre also\netwas, bei dem wir eine Bindung zu einem\nHändler eingehen können.  Wir können Ausgabenrichtlinien durchsetzen.\nEs kann API-gesteuert und somit\nprogrammatisch sein.  Und Sie können\nüberprüfbare Identitäten haben.\nIch werde also über drei\nverschiedene Dinge sprechen, die Stripe und unsere\nPartner gemeinsam im Bereich\nAnmeldeinformationen, Zahlungsabläufe und Checkout entwickelt haben, um zu\nveranschaulichen, wie wir versuchen,\nall diese Probleme zu lösen.\nZunächst möchte ich über gemeinsam genutzte\nZahlungstoken sprechen.\nUnd die Idee dahinter ist, dass\nerstens nicht alle Zahlungsmethoden\nuniversell einsetzbar sind, wie beispielsweise Kreditkarten.\nÄhm, manche werden auf unterschiedliche\nWeise ausgedrückt.  Ähm, aber es gibt auch keine Möglichkeit,\nAusgabenlimits oder Kontrollen durchzusetzen, wenn\nman einfach jemand anderem eine Kartennummer gibt\n, richtig?  Sie werden darauf vertrauen,\ndass sie den Betrag berechnen, den Sie\nvon der Seite ausgelesen haben oder was auch immer.\nUnd was wir mit gemeinsam genutzten Zahlungstokens geschaffen haben,\nist die Idee, dass ein Agent\neine Zahlungsanmeldeinformation sammelt und diese\nmit dem Verkäufer teilen kann, und zwar\nüber Hunderte von verschiedenen\nZahlungsmethoden hinweg.  Und es kann gewissermaßen wie\nein Mandat oder ein Smart Contract die\nBeschränkungen dieser Anmeldeinformationen für\neinen bestimmten Verkäufer kodieren.\nWir werden Ihnen gleich eine Demo zeigen\n, aber ich kann Nutzungslimits für\nbestimmte Währungen, Beträge,\nZeiträume und bestimmte Verkäufer festlegen.\nSelbst wenn ich also, sagen wir mal,\nvon einer Domain getäuscht wurde oder\nden Betrag nicht\nrichtig berechnet habe, kann ich immer noch das anwenden, was ich für\nrichtig halte, und zwar in Bezug auf den Betrag\nund den jeweiligen Verkäufer, den ich im\nVisier habe.\nAlso nochmal: Der Geltungsbereich liegt beim Verkäufer, die Einhaltung der Regeln wird\nvon Stripe durchgesetzt, die Regelung gilt für alle\nZahlungsmethoden und sie ist\nüberprüfbar.  Ich werde Ihnen daher kurz eine\nDemo geben, um Ihnen zu zeigen, wie das\nfunktioniert.\nSchauen wir uns also eine typische\nStripe-Integration an.\nIch habe also mein Stripe-Verkäuferkonto und\nmöchte 50 Dollar berechnen.  Normalerweise\nwürde ich also eine Zahlungsabsicht erstellen und in\nZeile 39 diese Zahlungsmethode\nselbst erfassen, und dann würde es funktionieren, und das ist alles\nsuper.  Ähm,\naber anstatt die\nZahlungsmethode auf meiner Website zu erfassen, erfasst nun ein Agent\neine Zahlungsmethode, die er\nmöglicherweise bereits von seinem menschlichen\nBediener oder über das Abonnement erhalten hat,\ndas dem Gurtzeug oder was auch immer zugrunde liegt\n.  Wir werden also ein\nzweites Stripe-Konto einrichten.  Und dies ist das\nStripe-Konto des Agenten.\nUnd es wird ein gemeinsames\nZahlungstoken bereitstellen.  Nehmen wir an, es hätte\neine Visa-Karte eingesammelt.\nUnd es wird angezeigt, dass diese Visa-\nKarte, die ein viel höheres Kreditlimit hat\n, nur für Beträge ab 25 Dollar funktioniert und\nnur für die nächsten 30\nTage gültig ist und dass sie auf diesen bestimmten\nVerkäufer beschränkt ist, beispielsweise auf mein internes\nTestkonto.\nWir werden also jetzt damit beginnen und\ndiese Anmeldeinformationen erstellen.\nAnstatt eine der von ihnen gesammelten Zahlungsmethoden zu verwenden, erhält der Verkäufer\nein\nihm zugewiesenes Token\nund versucht, die Zahlung durchzuführen.\nAlso, lasst uns\ncool sein.  Als Erstes sehen wir also, dass\nwir dieses neue gemeinsame Zahlungstoken erstellt haben\n,\ndas für diese Visa-Karte gilt, es ist\naktiv, es hat dieses Limit von 25 Dollar und es läuft\nin 30 Tagen ab.\nWichtig ist dabei\nauch, dass der Verkäufer nicht\nvöllig von den Vorgängen ausgeschlossen wird.  So wie\nsie\nsonst eine Karte gesammelt und die\nMarke, die letzten vier Ziffern usw. gekannt hätten,\nübermitteln wir ihnen diese Informationen trotzdem.\nDie Marke und die letzten vier Faktoren, die\nKreditart, können sie alle\nin ihre bestehende Risikoanalyse einbeziehen.\nEin weiterer wichtiger Aspekt ist, dass\nwir nichts\nvor dem Verkäufer geheim halten wollen.  Wir möchten\ndem Verkäufer dennoch die relevanten Informationen zur Verfügung stellen,\ndamit er\nseine bisherigen Risikomanagementsysteme weiterhin anwenden kann,\ndamit er die\nZahlung akzeptieren kann.  Ähm, aber wir werden sehen, dass wir\nhier tatsächlich einen Fehler hatten.  Der\nangeforderte Betrag, nämlich 50 Dollar, ist also\nhöher als der\nvorgeschriebene Betrag.  Also, nochmal: Wir haben\nAnmeldeinformationen gesammelt, diese weitergegeben, ein\nLimit festgelegt, dem Verkäufer vertraut, der Verkäufer hat\nversucht, mehr zu tun, und jetzt hat Stripe\neine Beschränkung durchgesetzt.  Also, äh, nochmal\n,\ndas würde mit jeder Zahlungsmethode funktionieren\n, und, wissen Sie, jetzt, wo wir\ndie Kosten senken können, werden\nwir sehen, ob das auch tatsächlich klappt\n.\nJa, die Zahlung ist durchgegangen.  Jetzt\nkönnen wir also Anmeldeinformationen sicher senden\n, Beschränkungen festlegen, den potenziellen\nSchaden minimieren\nund dem Verkäufer trotzdem ermöglichen,\nZahlungen wie gewohnt abzuwickeln.  Damit wäre das Thema „\nFreigabe von Anmeldeinformationen“ abgedeckt,\naber es gibt noch zwei weitere Aspekte.\nWie genau verknüpfen wir eine Zahlung mit\neinem Produkt, und wie funktioniert dann der\nBezahlvorgang?  Also,\ndas zweite, was wir entwickelt haben – in\nZusammenarbeit mit unseren Freunden von Tempo – war\ndas sogenannte Machine Payments\nProtocol.  Um auf den ursprünglichen\nPunkt bezüglich der Tool-Aufrufe zurückzukommen: Nun ja, Tool-\nAufrufe sind im Grunde HP-Anfragen, die\nAgenten stellen können.  Ähm, und HP-Anfragen\nsollten bezahlt werden können, richtig?\nEine Möglichkeit besteht also darin, einen API-Schlüssel zu übergeben,\naber manchmal sind diese Interaktionen mit den\nTools nur von kurzer Dauer.  Wir möchten also in der Lage sein,\ndie Zahlungspflicht\nin diesen HP-Anfragen durch die Rückgabe des\nStatuscodes 402 zu kommunizieren und dann die\nzuvor gezeigten Anmeldeinformationen anzugeben, damit\nwir tatsächlich eine positive Antwort erhalten.\nAlso, ähm,\nwir haben besprochen, wie wir an\nZugangsdaten gelangen, wie wir\nsie bezahlen müssen und wie wir sie dem eigentlichen\nProdukt zuordnen, das wir kaufen?  Also, um es nochmals zu sagen:\nDas Fenster des verbesserten Determinismus schließt sich\n.\nAlso, Determinismus maximieren.  Lass uns eine Demo machen.\nSo, wenn wir jetzt hierher wechseln, werde ich\neinen Server starten.\nDieser Server ist ein ganz normaler\nWebserver.  Es verfügt über geschützte\nEndpunkte, die nun eine Zahlung erfordern.   Nehmen wir also an,\nmein Roboter ruft einen\ndieser Endpunkte auf, um ein\nTool auszuführen.\nFühre eine curl-Anfrage daran aus.\nEs schlägt fehl.\nSagt uns, dass wir bezahlen müssen.\nEs liefert uns eine Art\nkodierte Nutzlast, die erklärt, was wir\nkaufen, für wen wir bezahlen, wofür\nwir bezahlen und wie die\nBezahlung abläuft.\nÄhm,\nund ich kann es\njetzt bezahlen.\nDa wir dieses Protokoll verwenden, erhalten wir nun zusätzliche Informationen.  Wir\nkönnen sehen, dass es diesen speziellen Empfänger einen Cent kosten wird\n.\nÄhm, es wird Path USD auf der Tempo-\nBlockchain sein.  Und ich kann es\ngenehmigen.   Wenn das nun\ndurchgelaufen ist und wir unseren\nErfolg erzielt haben, können wir sehen, wie eine\nTransaktion auf der Blockchain landet.\nWir können also\nAnmeldeinformationen erstellen, die nur eingeschränkt nutzbar sind.  Nun\nkann uns ein Verkäufer mitteilen, wie er das\nGeld haben möchte, und es wird\nmit der tatsächlichen Ressource verknüpft, die ich\nanfordere.  Und jetzt kann ich ihnen\nGeld schicken.\nÄhm, aber der letzte Teil ist, ähm, lasst uns einfach wieder einsteigen\n.\nEs ist ja nicht so, als würden\nwir immer API-Aufrufe kaufen,\nrichtig?  Und manchmal spielen die Details\ndes Kaufs eine ziemlich große Rolle,\nnicht wahr?  Die Steuerhöhe, vielleicht gibt es\ndas, äh, es gibt Beschränkungen hinsichtlich der\nMenge der Dinge, die ich kaufen könnte.  All das, was\neine typische E-Commerce-Website\nvermitteln möchte.  Und um auf den vorherigen\nPunkt zurückzukommen, nämlich den Roboter, der sich auf\neiner Checkout-\nSeite herumirrt: Es gibt viele Details, die wir\ndem\nAgenten und letztendlich dem menschlichen\nKäufer zurückmelden möchten, um sicherzustellen, dass das, was wir\nkaufen, auch das ist, was wir zu\nkaufen glauben, richtig?  Wir möchten\nStreitigkeiten, Rückbuchungen usw. minimieren.  Und\nwenn wir diese Proxy-Schicht des Agenten\ndazwischen haben, laufen wir Gefahr, dass\ndiese Details falsch weitergeleitet werden.\nWas wir also mit Open AI als\nAgent-to-Commerce-Protokoll entwickelt haben, ist ein Standardsatz\nvon APIs und Objekten, der erklären kann,\nwie Bezahlvorgänge im Web funktionieren.   Ähnlich wie\nbeim letzten Beispiel, bei dem\nder Verkäufer die\nZahlungsaufforderung signalisiert, richten wir einen Dialog\nzwischen Agent, Verkäufer und dessen\nZahlungsdienstleister ein.\nJedes Mal, wenn der Agent eine Bestellung\naufgeben, die\nMenge aktualisieren oder die Versandkosten festlegen möchte,\nkann der Verkäufer über ein Tool\nnamens Relay Back den aktuellen Status übermitteln,\nauf diese Anfrage reagieren und letztendlich die\nZahlung veranlassen.\nWir können also anhand eines realen Unternehmens veranschaulichen, wie das\nfunktioniert\n.\nLasst uns\nhier einen Server starten.\nStripe betreibt also etwas namens Stripe\nPress.  Das ist unser Bücherladen.  Das ist\nnatürlich eine sehr coole, menschenfreundliche Art, die Sache\nzu betrachten, aber unsere Entsprechung\nist die roboterfreundliche Art, die Sache zu betrachten\n.\nDas ACP-Protokoll bzw. ACP umfasst also einige\nDinge.  Wie stellt man einen\nProduktkatalog dar?  Anstatt dass der Roboter also\nherumstolpert, auf\nLinks klicken und herausfinden muss, was er kaufen soll, können wir\nunsere Produkte einfach in JSON mit\nBildern, Beschreibungen und Preisen darstellen.\nUnd dann kann der Roboter einen dieser Artikel auswählen\nund den Bezahlvorgang einleiten.\nAlso, äh\n,\nwir können eine vertraute Benutzeroberfläche aufrufen, vielleicht\nfrage ich nach Empfehlungen für KI-\nBücher.\nUnd auf der rechten Seite sehen wir die\nAnfragen, die der Agent stellt.  Es\nverrät also ein wenig über den Käufer,\ndie gewünschten Artikel und Mengen.\nUnd dann kann der Verkäufer\nim Prinzip den Status des Warenkorbs zurückmelden.\nAnstatt dass der Roboter also versucht,\nInformationen aus\neiner Benutzeroberfläche wie dieser zu extrahieren, verfügt er über strukturierte Daten, auf\ndie ich zurückgreifen kann.  Also,\näh, die einzelnen Positionen, der\njeweilige Grundpreis, die anfallende Steuer, die verschiedenen\nVersandoptionen und so weiter.  Also,\nnichts Überraschendes, aber, wissen Sie,\nunser Ziel ist es ja, diesen Determinismus gewissermaßen zu etablieren\n, richtig?  Wo wir\nvon der Entdeckungsphase, in der wir vielleicht\nWeb-Crawling betrieben haben,\nzu einer rein programmatischen\nHin- und Herbewegung übergegangen sind.\nWenn ich also die Zahlungsmethode\noder die Versandart ändere\nund schließlich bezahle, kommt es zu diesen Änderungen\n.  Die Zahlungen\nerfolgen über die Verwendung eines\ngemeinsamen Zahlungstokens oder auf andere Weise, um\ndiese Anmeldeinformationen weiterzuleiten.\nIch prüfe das noch einmal.   Ja.\nLetztendlich verfügen wir also über\nAPI-gesteuerte Handelsabläufe, die\nflexibel auf verschiedene Zahlungsmethoden reagieren, egal ob es sich um\nKryptowährungen, Karten oder eine der\nHunderten anderen\nexistierenden Zahlungsarten handelt.  Und ganz entscheidend ist, dass der Verkäufer die\nKontrolle behält.  Sie pflegen weiterhin\ndie Beziehung zu ihren Kunden, die sie erwartet haben,\nerhalten aber gleichzeitig\ndie Signale und Risikodaten, die sie\nfür eine sichere Interaktion mit den Agenten benötigen.\nUnd das versteht sich von selbst, die\nmeisten von uns haben\ndas mit unseren\nProdukten bereits getan, aber wir wollen\nunsere Produkte agentenfreundlich gestalten.  Ähm, und wenn\nwir Ihnen nur Web-UIs oder\nähnliche Anwendungen zur Verfügung stellen, erhöhen wir\ndie Wahrscheinlichkeit, dass\nNicht-Determinismus mit unseren\nGeschäftsprozessen interagiert.  Stattdessen sollten wir sie\naltersgerecht gestalten, agentenfreundlicher, um\ndie deterministischen Abläufe zu maximieren, die\nAgenten mit unseren Unternehmen haben.  Daher\nist es für Agenten wichtig, Dinge wie gemeinsam genutzte Zahlungstoken oder Wallets oder andere Technologien zu nutzen, um diese Anmeldeinformationen sicher zu verwalten, damit\nsie\nnicht versehentlich eine Unmenge\nDollar mit einer Karte ausgeben.   Also, kurz\ngesagt: Entdeckungen sollten wir mit dem\nNichtdeterminismus fortsetzen, das ist perfekt.  Zahlungen,\nCheckout und Anmeldeinformationen wollen wir\nausschließlich deterministisch gestalten.   Ein\nnicht-deterministischer Planer und\nBeschränkungen mit überprüfbaren Parteien und\nstrukturierten Verhandlungen führen zu einem\nkleinen Risikoradius und hoffentlich sicheren\nZahlungen zwischen Agenten und\nUnternehmen.  Das ist also alles, was ich habe.  Danke schön\n.\nIch habe 2 Minuten und 9 Sekunden Zeit, falls es\nFragen gibt.\nSie erwähnten Blockchain.   Ja\n.\nWird das von Temple gehostet oder von\nStripe, oder besitzen sie ihre eigenen, separaten\nDaten?\nJa, also Stripe unterstützt eine\nReihe verschiedener Protokolle und\neine\nVielzahl von Netzwerken, darunter Base\nund Tempo.  Die Transaktionsdaten befinden sich\nnaturgemäß auf diesen Blockchains, und\nStripe bildet dann die\nProduktansicht dieser Daten in unserem eigenen System ab.   Ja.\nAber warum sollte man\ndiesen Kerl berücksichtigen?\nDie gemeinsamen Zahlungstoken sind echt\ncool.\nÄh, wenn es um wiederkehrende\nBudgets und Zahlungen geht, ich denke da zum Beispiel daran, dass\nich Open Claw\n25 Dollar pro Woche für die Nutzung mit\neinem bestimmten Modell geben möchte.  Wie genau spielt das eine\nRolle?\nJa, Sie haben also zwei Punkte angesprochen: die\nSache mit den Abonnements und dann die eher\nlangfristigen Richtlinien.  Was\nAbonnements angeht, ist es ähnlich wie bei der Ausgabe\neiner Kreditkarte\nan ein Unternehmen, mit der man diesem\nregelmäßig Ausgaben in Höhe von beispielsweise 25 Dollar erlaubt, wobei\naber weiterhin dieselben Zugangsdaten verwendet werden.\nÄh, wir haben dort auch eine ähnliche Idee.\nÄhnlich wie beim OAuth-Zugriffs- und\nAktualisierungsablauf, wo man sozusagen die\nnachfolgende Nutzung anfordern kann.  Ähm, und dann noch ein\nanderer Aspekt, wie zum Beispiel\nausgeglichenere Haushalte.\nHier kann eine Art Äquivalenzprinzip funktionieren, bei dem man\neinfach eine höhere Zahl wählt.\nWir beschränken das Angebot weiterhin auf einzelne Verkäufer,\naber man könnte theoretisch unendlich viele davon erstellen\n.\nÄhm, ich frage mich also, ob Stripe-Projekte im Grunde\nnur eine Hülle für diese\nGrundbausteine ​​sind, die Sie während\nder Sitzung besprochen haben?\nÄh ja.  Danke für die Werbung.  Ich\nhatte keine Zeit, das zu erwähnen, aber ja,\nStripe-Projekte basieren auf gemeinsam genutzten\nZahlungstoken.  Und dann die Art und Weise,\nwie Verkäufer oder\nSAS-Unternehmen ihre Produkte präsentieren können.\nUnd dann wurde der Punkt angesprochen, der den\nwiederkehrenden Teil betrifft, nämlich wie der\nmonatliche Teil funktionieren würde.\nDanke schön.\nSie erwähnten, dass Sie damit vor\n2 Jahren begonnen haben.  Mich interessiert die\nAnzahl und das Volumen solcher Zahlungen.\nKönnen Sie uns dazu etwas mitteilen?\nWir haben dazu keine öffentlichen Statistiken,\naber im Allgemeinen sind wir sehr\nermutigt davon und freuen uns darauf,\nmehr Unternehmen bei der\nAkzeptanz dieser Zahlungsart zu unterstützen.   Nun\n, ich bin wieder bei Null, also vielen Dank an\nalle.  Vielen Dank.",
  "transcript_chars": 21049,
  "ingested_at": "2026-06-15T00:54:58.982499+00:00",
  "source": "channel",
  "yt_meta": {
    "view_count": 1933,
    "like_count": 45,
    "channel_id": "UCLKPca3kwwd-B59HNr-_lvA",
    "categories": [
      "Science & Technology"
    ],
    "tags": [
      "ai",
      "ai engineer",
      "ai engineering",
      "software development",
      "tech",
      "startups",
      "software architecture",
      "machine learning"
    ]
  }
}