Analyse der AkzeptanzÖffentliche Vorschau

Auf der Seite Akzeptanz im Stripe-Dashboard können Sie Ihre Zahlungserfolgsquote und Autorisierungsquote analysieren, um herauszufinden, wo genau Zahlungen fehlschlagen, warum sie fehlschlagen und wie Sie diese Informationen nutzen können, um Ihren Umsatz zu steigern. Um diese Seite anzuzeigen, navigieren Sie zu Zahlungen > Analysen > Akzeptanz.

Die Seite „Akzeptanz“ im Dashboard enthält folgende Daten für Kartenzahlungen:

• Erfolgreiche Zahlung und Netzwerkautorisierungsquote (entweder als Rohdaten oder dedupliziert)
• Pivot-Diagramme für gängige Dimensionen (auch als Filter erhältlich)
• Gründe für fehlgeschlagene Zahlungen (Authentifizierungsproblem, Blockierungen oder Ablehnungsgründe des Kartennetzwerks)
• Die Verbesserung durch die Funktionen zur Zahlungsoptimierung von Stripe

Verfügbare Daten

Daten auf dieser Seite umfassen versuchte und autorisierte Kartenzahlungen.

Versuchte Zahlungen

Wenn Ihre Kundinnen/Kunden versuchen zu zahlen, sendet Stripe die Zahlungsdetails über Kartennetzwerke wie Visa, Mastercard oder China UnionPay. Anschließend senden die Kartennetzwerke die Anfragen an die entsprechenden kartenausstellenden Banken, die die Zahlungen entweder autorisieren oder ablehnen.

Ein Zahlungsversuch kann in mehreren Schritten fehlschlagen, sogar bevor eine Zahlung an das Kartennetzwerk gesendet wird. Beispielsweise könnte die 3D Secure-Authentifizierung (3DS) fehlschlagen oder von Stripe Radar blockiert werden. Nachdem eine Zahlung an das Kartennetzwerk gesendet wurde, können Kartenaussteller diese aus verschiedenen Gründen ablehnen, z. B. unzureichende Deckung auf dem Kartenkonto oder falsche Karteninformationen. Es kann vorkommen, dass Kartenaussteller legitime Zahlungen wegen Betrugsverdachts fälschlicherweise ablehnen.

Autorisierte Zahlungen

Bei autorisierten Zahlungen wird nicht berücksichtigt, ob die Zahlungen letztendlich erfasst wurden. Erfahren Sie mehr über den Unterschied zwischen Autorisierung und Erfassung.

Ihren Datensatz konfigurieren

The filters at the top of the Payments analytics page apply to all metrics, charts, and tables on the page. Stripe processes your data daily starting at 12:00 am UTC and ending at 11:59pm UTC. All data shown is in the UTC time zone.

Währung angeben

If you don’t apply a currency filter, all payments are shown and converted to your default settlement currency, even if the original payment is in a different currency.

If you apply a currency filter, you only see data for payments made in the selected currency. For example, if you use the currency filter to switch from USD to EUR, you’ll only see transactions made in EUR, excluding those in other currencies such as USD.

To change the currency, click + More filters > Currency, and select the currency you want from the list.

Connect angeben

Connect-Plattformen sehen die Aktivitäten zu Direct Charges für alle verbundenen Konten zusammengefasst. Daten von Standard-Konten sind nur für Plattformen sichtbar, wenn Sie Plattform-Steuerungen aktivieren.

Um Daten verbundener Konten einzubeziehen, klicken Sie auf Verbundene Konten einschließen. Um einen Ausschluss vorzunehmen, klicken Sie auf Verbundene Konten nicht einschließen.

Zahlungserfolgs- oder Autorisierungsquoten angeben

Verwenden Sie den Quotenfilter, um Ihre Analysen anhand der Quote erfolgreicher Zahlungen oder der Autorisierungsquote zu überprüfen.

Um die Quote erfolgreicher Zahlungen anzugeben, klicken Sie auf Quote erfolgreicher Zahlungen. Um eine Autorisierung anzugeben, klicken Sie auf Autorisierungsquote.

Nachfolgend finden Sie ein Beispiel für die Berechnung der Autorisierungsquote und der Quote erfolgreicher Zahlungen:

Deduplizierte Daten im Vergleich zur Rate der Rohdaten

Um Ihre erfolgreiche Zahlung und die Netzwerkautorisierungsquote anzugeben, klicken Sie entweder auf Rohdaten oder Dedupliziert.

Bei einigen Zahlungsversuchen handelt es sich um Wiederholungsversuche eines eindeutigen Kaufs. Zum Beispiel wird der ursprüngliche Zahlungsversuch einer Kundin/eines Kunden abgelehnt, weil sie/er die falsche Prüfziffer/CVC eingegeben hat und die Zahlung später erneut einreicht, nachdem der Fehler korrigiert wurde. Mit Ausnahme ungültiger API-Anfragen beziehen wir alle Zahlungsversuche in diese Berechnung ein. Die Rate der Rohdaten zählt alle Versuche für eine Zahlung, während die deduplizierte Quote die wiederholten Versuche zusammenfasst und die Akzeptanzquote basierend auf dem Endergebnis berechnet.

Die folgende Tabelle zeigt Beispielberechnungen unter Verwendung der deduplizierten Rate und der Rohrate:

Wenn Sie sich die Quoten der deduplizierten Zahlungen ansehen, sehen Sie möglicherweise einen vorübergehenden Rückgang Ihrer Erfolgs- oder Autorisierungsquoten für den letzten Monat, wenn noch nicht alle Zahlungsversuche wiederholt wurden.

Sie können auch selbst Wiederholungsversuche planen. Diese Vorgehensweise (genannt „Dunning“ bzw. im Deutschen Mahnwesen) ist bei Unternehmen mit wiederkehrendem Umsatz üblich. Wenn Sie Mahnungen mit Stripe Billing nutzen, hebt Stripe den entsprechenden Teil der Tabelle anhand Ihrer Billing-Einstellungen hervor.

Bei Zahlungen per Stripe Invoices gruppieren wir Zahlungsversuche auf derselben Rechnung. Bei Zahlungen mit Kundinnen/Kunden gruppieren wir Versuche für dieselbe Kundin/denselben Kunden, wenn diese zeitlich nahe beieinander liegen und den gleichen Betrag erzielen. Alle anderen Zahlungen werden unter derselben Kartennummer für zeitlich nahe beieinander liegende Versuche und für denselben Betrag gruppiert.

Akzeptanzdaten herunterladen

Sie können alle Daten herunterladen, die zur Erstellung des Berichts verwendet wurden. Downloads enthalten Zahlungen, die den Filtern oben im Bericht entsprechen. Das Download-Dialogfeld ist nur auf einen Währungsfilter festgelegt (standardmäßig die Währung des Unternehmens).

Um diese Analysen herunterzuladen, klicken Sie oben in jedem Diagramm auf Herunterladen .

Bericht über die wichtigsten Metriken

Dieser Bericht zeigt die wichtigsten Metriken für die von Ihnen ausgewählten Filter, einschließlich der Quote sowie der Anzahl der autorisierten Zahlungen und des autorisierten Zahlungsvolumens. Die Zeitreihe vergleicht die Quote mit einer previous_period, die Sie anpassen können. Standardmäßig beginnt der Vergleichszeitraum direkt vor dem von Ihnen gewählten Zeitraum und stellt die gleiche Zeitdauer dar.

Zahlungsbericht

Der Zahlungsbericht ermöglicht es Ihnen, Kartenakzeptanzmetriken über mehrere gängige akzeptanzfördernde Dimensionen hinweg anzuzeigen. Jeder der Filter der obersten Ebene verfügt über ein entsprechendes Pivot-Diagramm. Durch die Verbindung der Filterfunktionen mit den Pivot-Diagrammen im Zahlungsdiagramm ergibt sich eine Ansicht, mit der Sie überwachen können, wie sich verschiedene Zahlungsgruppen im Laufe der Zeit verhalten. Sie können durch die einzelnen Registerkarten aufrufen, um die Raten, die Aufschlüsselung der Anzahl der Zahlungen (in absoluten Zahlen oder als Anteil der Zahlungen) und das Zahlungsvolumen zu vergleichen.

Verwenden Sie alle diese Registerkarten, um zu sehen, wie sich Änderungen des Preises auf Änderungen der Anzahl oder des Volumens von Zahlungen auswirken. Mit Sigma können Sie interessante Trends noch genauer untersuchen. Sie können außerdem den aufgeschlüsselten Download verwenden, um nach verfügbaren Zahlungsattributen zu filtern. Zum Beispiel können Kartentests zu einer Senkung der Rate und einem plötzlichen Anstieg der Anzahl der Zahlungen führen.

Analysieren Sie Zahlungen und welche Optionen möglich sind, wie z. B. welche Kartenmarken, Länder oder Eingabemethoden Ihre Kundinnen und Kunden zum Bezahlen verwenden.

Kartentyp

Im Durchschnitt sind die Erfolgsquoten bei Kreditzahlungen höher als bei Debitzahlungen, welche wiederum höher sind als Erfolgsquoten von Prepaid-Zahlungen. Dies liegt in der Regel daran, dass Zahlungen per Debit- und Prepaid-Karten eher abgelehnt werden, wenn nicht genügend Gelder vorhanden sind, um die Einkäufe abzuschließen.

Land der Karte

Das Kartenland bezieht sich auf das Land des Kartenausstellers, nicht auf den physischen Kundenstandort zum Zeitpunkt der Zahlung. Im Durchschnitt sind die Erfolgsquoten im Inland höher als bei grenzüberschreitenden Zahlungen (wenn sich also das Kartenland und Ihr Unternehmen in unterschiedlichen Regionen befinden). Dieser Hinweis kann Ihnen auch dabei helfen, herauszufinden, wo Ihre Kundinnen und Kunden ansässig sind.

Transaktionstyp

Die Kartennetzwerke unterteilen Kartenzahlungen in zwei Arten, je nachdem, ob die Kundin/der Kunde am Zahlungsablauf beteiligt ist oder nicht: Kundenseitig initiierte Transaktionen (Customer-Initiated Transactions, CITs) und händlerseitig initiierte Transaktionen (Merchant-Initiated Transactions, MITs). Kartenaussteller weisen diesen Transaktionstypen unterschiedliche Merkmale und Risikoprofile zu, sodass deren Erfolgsquoten in der Regel unterschiedlich ausfallen.

Eingabemethode

Bei Digital Wallets wie Apple Pay und Android Pay fallen die Erfolgsquoten im Vergleich zu normalen Online-Kartenzahlungen in der Regel höher aus. Grund hierfür sind die Tokenisierung und Authentifizierung per Gerät, was ein höheres Maß an Vertrauen beim Kartenaussteller erzeugt.

Wenn Sie Stripe Terminal verwenden, sehen Sie möglicherweise auch die Option Card Present (Karte vorhanden) als Eingabemethode, was persönliche Zahlungen darstellt. Branchenweit sind die Erfolgsquoten von Card-Present-Zahlungen in der Regel höher als bei Card-Not-Present-Zahlungen. Die physische Karte muss zum Zeitpunkt des Kaufs bei persönlichen Zahlungen vorhanden sein. Diese Zahlungen haben daher oft ein geringeres Risikoprofil für Kartenaussteller als dies bei Online-Zahlungen der Fall ist.

Status der gespeicherten Karte

Sie können zuvor gespeicherte Kartendaten verwenden, um Kundenkarten zu einem späteren Zeitpunkt zu belasten. Diese Option wird am häufigsten für Abonnements verwendet. Eine gespeicherte Karte wird auch als Credential-on-File (CoF) bezeichnet. Die Erfolgsquoten sind in der Regel für gespeicherte Karten höher als für nicht gespeicherte Karten.

Antwort nach Postleitzahl

Address Verification Service (AVS) ist ein Tool zur Identitätsverifizierung, mit dem Unternehmen potenziell betrügerische Kredit- oder Debitkartenzahlungen erkennen und verhindern können. Dies geschieht, indem sie die von Kundinnen und Kunden angegebene Rechnungsadresse mit der beim Kartenaussteller gespeicherten Rechnungsadresse der Kundinnen und Kunden vergleichen, um die Übereinstimmung zu bestätigen. Die Adressverifizierung wird hauptsächlich von Kartenausstellern in den Vereinigten Staaten, Kanada und dem Vereinigten Königreich unterstützt.

In der folgenden Tabelle werden Beispielwerte für die Antwortmetrik auf die Postleitzahl angezeigt.

CVC-Antwort

Die Prüfziffer/CVC (auch CVV genannt) ist die drei- oder vierstellige Prüfziffer, die auf eine Karte aufgedruckt ist, und sich in der Regel auf dem Unterschriftsstreifen oder der Vorderseite der Karte befindet. Wenn eine Kartenzahlung zur Autorisierung an ein Kartennetzwerk übermittelt wird, sendet Stripe den CVC, insofern dieser bereitgestellt wurde. Ähnlich wie bei AVS prüft der Kartenaussteller im Rahmen einer zusätzlichen Verifizierung die Prüfziffer/CVC anhand der Informationen, die er für die Kundin/den Kunden hinterlegt hat. Wenn die bereitgestellten Informationen nicht übereinstimmen, schlägt die CVC-Verifizierungsprüfung fehl, was zu einer abgelehnten Zahlung führen kann. Eine fehlgeschlagene CVC-Prüfung kann darauf hindeuten, dass eine Zahlung betrügerisch ist. Prüfen Sie das Ergebnis daher sorgfältig, bevor Sie die Bestellung abwickeln.

In der folgenden Tabelle werden Beispielwerte für die Antwortmetrik auf die Prüfziffer/CVC angezeigt.

Nutzung von Netzwerk-Token

Ein Netzwerk-Token (NT) ist ein nicht sensibler, 16-stelliger numerischer Ersatz für die Nummer auf der Vorderseite der Karte, die auch als primäre Kontonummer (PAN) bezeichnet wird. In Verbindung mit einem Kryptogramm kann in der Autorisierungsnachricht anstelle einer PAN ein Netzwerk-Token an das Kartennetzwerk gesendet werden.

Im Gegensatz zu PANs handelt es sich bei Netzwerk-Token um Anmeldedaten für Zahlungen, die dynamisch auf bestimmte Unternehmen und Kanäle beschränkt werden können. Dadurch werden das Risiko und die Auswirkungen potenzieller Sicherheitsverletzungen und Angriffe gesenkt. Unternehmen verwenden NTs auch, um ihre Autorisierungsquote zu steigern. Netzwerken liegen die neueste Zuordnungen zwischen NTs und PANs vor, sodass Stripe weiterhin dasselbe NT verwenden kann, auch wenn sich die zugrunde liegende PAN ändert. Ablehnungen von legitimen Zahlungsversuchen werden dadurch vermieden.

„Sonstige“ genauer analysieren

Bei Dimensionen mit mehreren Optionen beinhaltet das Pivot-Diagramm eine Kategorie mit der Bezeichnung „Sonstige“, die Datenpunkte mit geringem Volumen zusammenfasst, die auf dem Diagramm nicht dargestellt werden. Beispiel: Unter Umständen möchten Sie alle Ausstellungsländer in Ihren Daten sehen. Dazu können Sie die Daten in Sigma einsehen oder herunterladen.

Fehlgeschlagene Zahlungen

Anhand dieser Tabelle können Sie herausfinden, warum Zahlungen fehlgeschlagen sind oder abgelehnt wurden.

Bevor die Zahlung an das Kartennetzwerk gesendet wird

In den folgenden Abschnitten werden Fehler beschrieben, die auftreten, bevor die Zahlung an das Kartennetzwerk gesendet wurde.

Authentifizierung fehlgeschlagen

Sie können die Zahlungsauthentifizierung mit 3D Secure (3DS) über die API oder mit einer Radar-Regel anfordern. Es ist auch möglich, dass Stripe 3DS auslöst, um bestimmte Vorschriften einzuhalten, wie zum Beispiel die starke Kundenauthentifizierung (SCA) in Europa. Die Zahlungsanfragen, bei denen die Authentifizierungen fehlgeschlagen sind, stellen Situationen dar, in denen die Kundin/der Kunde die Schritte zur Authentifizierung nicht abgeschlossen hat oder die Authentifizierung aus anderen Gründen fehlgeschlagen ist. Weitere Informationen zu Authentifizierungsfehlern finden Sie unter Zahlungsanalysen.

Zahlungen nach Grund blockieren

Stripe Radar blockiert Zahlungen mit hohem Risiko, zum z. B. Zahlungen, bei denen die Prüfziffer/CVC oder die Postleitzahl nicht übereinstimmt. Dieses Produkt für die automatische Betrugsprävention wertet jede einzelne Zahlung aus, ohne dass Sie Maßnahmen ergreifen müssen. Bei blockierten Zahlungen handelt es sich um jene, die von Stripe blockiert wurden, wobei die Erstautorisierung vom Kartenaussteller eingeholt wurde, die Karte jedoch nicht belastet wird. Diese Vorsichtsmaßnahme trägt dazu bei, potenzielle betrügerische Zahlungen abzuwenden, die zu Zahlungsanfechtungen führen könnten. Weitere Informationen zu Blockierungsgründen finden Sie unten unter „Blockierte Zahlungen nach Grund“.

Nachdem die Zahlung an das Kartennetzwerk gesendet wird

In den folgenden Abschnitten werden Fehler beschrieben, die auftreten, nachdem die Zahlung an das Kartennetzwerk gesendet wurde.

Ausstellerablehnung

Wenn eine Zahlungsanfrage an den Kartenaussteller übermittelt wird, ermittelt dieser mithilfe automatisierter Systeme und Modelle, ob diese autorisiert wird. Wenn der Aussteller eine Zahlung ablehnt, teilt Stripe Ihnen den Grund mit, den der/die Aussteller/in angegeben hat. In einigen Fällen gibt der/die Aussteller/in einen bestimmten Ablehnungsgrund mit einem Ablehnungscode an. Viele Zahlungen werden jedoch in allgemeine Ablehnungen eingeteilt (die häufigste davon ist do_not_honor). Die Kartenaussteller/innen können aus Datenschutz- und Sicherheitsgründen Einzelheiten nur mit ihren Karteninhaberinnen/Karteninhabern und nicht mit Ihnen oder gar Stripe besprechen.

Bei den meisten Unternehmen lassen sich die häufigsten Ablehnungsgründe für von Ausstellern abgelehnten Zahlungen einigen bestimmten Kategorien zuordnen. Unten finden Sie Erklärungen und empfohlene Maßnahmen für häufige Ablehnungsgründe durch das Netzwerk. Eine vollständige Liste mit möglichen Gründen, aus denen Kartenaussteller eine Zahlung ablehnen können, finden Sie unter Codes für abgelehnte Zahlungen.

• Unzureichende Deckung: Zum Zeitpunkt der Autorisierung ist das Konto für den Zahlungsbetrag nicht ausreichend gedeckt. Bitten Sie die Kundin/den Kunden, eine andere Zahlungsmethode zu verwenden oder fordern Sie von der Kundin/dem Kunden eine Genehmigung an, um es später erneut zu versuchen.
• „Do not honor“ (Nicht berücksichtigen) und andere allgemeine Antworten (z. B. „Allgemeine Ablehnung“ oder „Dienstleistung nicht zulässig“): Der Aussteller hat sich entschieden, keine konkreten Gründe für seine Entscheidung anzugeben. Fordern Sie die Kundin/den Kunden auf, sich an den Kartenaussteller zu wenden, um weitere Informationen zu erhalten oder eine andere Zahlungsmethode auszuprobieren. Sie können auch selbst versuchen, die Zahlung zu wiederholen.
• Antworten wie falsche Kartennummer, falsche Prüfziffer/CVC und andere falsche Kartenangaben: Der Kunde/die Kundin hat falsche oder nicht mehr gültige Kartendaten eingegeben. Vergewissern Sie sich, dass Sie die die automatische Kartenaktualisierung aktiviert haben. Kontaktieren Sie den Kunden/die Kundin über verschiedene Kanäle, z. B. per E-Mail, Textnachricht oder In-App-Benachrichtigung, damit er/sie seine/ihre Zahlungsdaten erneut eingibt oder sich an seinen/ihren Kartenaussteller/in wendet, wenn die Probleme weiterhin bestehen. Versuchen Sie es andernfalls mit einer anderen Zahlungsmethode.
• Transaktion nicht zulässig: Der Kartenaussteller hat die Zahlung aus unbekannten Gründen abgelehnt, die sich auf die Karte beziehen oder zahlungsspezifisch sein können. Ein Beispiel für den letzteren Fall ist eine für die Karte nicht zugelassene Ausgabenkategorie des Händlers/der Händlerin (beispielsweise FSA-Karten für nicht berechtigte Artikel). Die Kundin/der Kunde sollte weitere Informationen beim Kartenaussteller erfragen (erneute Zahlungsversuche werden wahrscheinlich fehlschlagen, bis der Kartenaussteller kontaktiert wurde) oder es mit einer anderen Zahlungsmethode versuchen.
• Karte verloren oder gestohlen: Die Karte wurde durch die Kundin/den Kunden als verloren oder gestohlen gemeldet. Erneute Zahlungsversuche schlagen fehl. Die Kundin/der Kunde sollte sich an den/die Kartenaussteller/in wenden, um weitere Informationen zu erhalten. Teilen Sie dem Kunden/der Kundin nicht den genauen Grund der Ablehnung mit, für den Fall, dass die Zahlung nicht durch die/den rechtmäßige/n Karteninhaber/in getätigt wurde.

Diagramm für blockierte Zahlungen

Anhand dieser Tabelle erfahren Sie, warum einige Zahlungen blockiert wurden.

Regelübereinstimmung – Radar

Einige Zahlungen werden aufgrund einer in Radar konfigurierten Regel blockiert. Dies schließt Zahlungen aus, die Radar aufgrund ihrer Risikobewertung standardmäßig blockiert hat.

Regelübereinstimmung nach der Autorisierung – Radar

Einige Zahlungen werden aufgrund einer konfigurierten Regel in Radar auch dann blockiert, obwohl der Kartenaussteller die Zahlung autorisiert hat. Dies trifft besonders oft bei Radar-Regeln zu, bei denen eine Antwort des Kartenausstellers erforderlich ist. Dieser muss dann z. B. prüfen, dass die Postleitzahl oder die Prüfziffer/CVC mit den Daten übereinstimmen, die beim Kartenaussteller hinterlegt sind. Dies schließt Zahlungen aus, die Radar aufgrund ihrer Risikobewertung standardmäßig blockiert hat.

Hohes Risiko – Radar

Einige Zahlungen werden von Radar aufgrund ihrer Risikobewertung standardmäßig blockiert. Radar ermittelt diese Wertung anhand von maschinellem Lernen und Sie können die Mindestwertung, die standardmäßig blockiert wird, anpassen. Es gibt Radar-Regeln, die Zahlungen blockieren, nachdem sie autorisiert wurden.

Stripe

Einige Zahlungen werden aus anderen Gründen von Stripe blockiert, die hier nicht aufgeführt sind. Dabei handelt es sich beispielsweise um Zahlungen, die von Karten auf Ablehnungslisten initiiert wurden, die weltweit als betrügerisch eingestuft werden, oder Zahlungen aus sanktionierten Ländern. Darüber hinaus kann Stripe Zahlungen blockieren, die im Verdacht stehen, mit Kartentests verbunden zu sein.

Diagramm zur Zahlungsoptimierung

Die Lösungen von Stripe zur Maximierung der Autorisierungsquoten verhindern, dass legitime Zahlungen abgelehnt werden. Zu diesen Funktionen gehören Adaptive Acceptance, Kartenkontoaktualisierer und Netzwerk-Token.

Optimization calculations are estimates and aren’t guarantees of any outcomes. The data we provide is intended to help you inform your decision-making, in order for you to make your own independent determinations about whether to use these features. The calculation methodology for estimated impacts is also subject to change without prior notice. Refer to this page regularly to ensure you have the latest understanding of the estimated optimization feature benefits.

Adaptive Acceptance

Wenn Stripe eine Ablehnungsantwort vom Aussteller erhält, prüfen die Modelle für maschinelles Lernen sofort, ob Stripe die Anfrage wiederholen sollte, und wie die Autorisierungsanfrage angepasst werden muss, um die Wahrscheinlichkeit einer Annahme zu erhöhen. Diese Wiederholungsanfrage erfolgt in Echtzeit, bevor Stripe eine Zahlungsantwort an Sie zurückgibt. Der in diesem Bericht angezeigte Anstieg stammt von Zahlungen, die mithilfe von Adaptive Acceptance nach einer anfänglichen Ablehnung erfolgreich erneut durchgeführt wurden.

Aktualisierung des Kartenkontos

Kartendaten und Ablaufdaten ändern sich regelmäßig, sodass veraltete Kartendaten für Online-Unternehmen eine häufige Quelle für Ablehnungen sind. Stripe lässt sich in die wichtigsten Kartennetzwerke integrieren, um gespeicherte Kartenzahlungsinformationen automatisch zu aktualisieren, damit Sie über die neuesten Kartendaten verfügen. Der in diesem Bericht angezeigte Anstieg stammt aus erfolgreichen Zahlungen mit Karten, die innerhalb von 180 Tagen nach dem Zahlungsdatum aktualisiert wurden.

Netzwerk-Token

Netzwerk-Token sind sichere Zahlungsinformationen, die als Ersatz für Kartennummern dienen. Netzwerk-Token sorgen dafür, dass Sie Zahlungen mit den aktuellsten Anmeldedaten abwickeln, da diese auch dann aktuell bleiben, wenn sich die zugrunde liegenden Kartendaten ändern. Stripe hat Integrationen mit den wichtigsten Kartennetzwerken entwickelt, um Ihre Karten zu tokenisieren. Außerdem wird über Modelle für maschinelles Lernen ermittelt, wann ein Netzwerk-Token die maximale Erfolgsquote bietet. Der in diesem Bericht angezeigte Anstieg stammt von erfolgreichen Zahlungen mit Netzwerk-Token, deren zugrunde liegende Anmeldedaten innerhalb von 180 Tagen nach dem Zahlungsdatum aktualisiert werden.