Analyse der AkzeptanzÖffentliche Vorschau

Auf der Seite Analysefunktionen für Zahlungen im Stripe-Dashboard können Sie Ihre Zahlungserfolgsrate, Autorisierungsquote und Zahlungen analysieren. So finden Sie heraus, wo genau Zahlungen fehlschlagen, aus welchem Grund und wie Sie diese Informationen nutzen können, um Ihren Umsatz zu steigern. Um Ihre Analysefunktionen anzuzeigen, gehen Sie zu Zahlungen > Analysen Akzeptanz.

Zahlungsversuche verstehen

Wenn Ihre Kundinnen/Kunden Zahlungsversuche tätigen, sendet Stripe die Zahlungsdetails über die Kartennetzwerke wie Visa, Mastercard oder China UnionPay. Die Kartennetzwerke leiten die Anfragen dann an die entsprechenden Banken, die die Karten ausgestellt haben weiter, die die Zahlungen entweder autorisieren oder ablehnen.

Ein Zahlungsversuch kann zu mehreren Zeitpunkten fehlschlagen, selbst bevor eine Zahlung an das Kartennetzwerk gesendet wird. So können Zahlungen beispielsweise fehlschlagen, weil sie die 3D Secure-Authentifizierung (3DS) nicht bestanden haben oder von Stripe Radar blockiert werden. Nachdem die Zahlung an das Kartennetzwerk gesendet wurde, können die Kartenaussteller diese aus verschiedenen Gründen ablehnen, zum Beispiel aufgrund unzureichendem Guthaben auf dem Kartenkonto oder wegen falscher Karteninformationen. Gelegentlich lehnen Aussteller bei Verdacht auf Betrug fälschlicherweise auch legitime Zahlungen ab.

Die Analysefunktionen der Zahlungen liefert die folgenden Daten für Kartenzahlungen:

• Zahlungserfolg und Netzwerkautorisierungsquote, die Sie entweder als Rohwert oder dedupliziert anzeigen können
• 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

Die Daten auf dieser Seite umfassen versuchte und autorisierte Kartenzahlungen. Bei autorisierten Volumenangaben wird nicht berücksichtigt, ob die Zahlungen letztendlich erfasst wurden. Erfahren Sie mehr über die Unterscheidung zwischen Autorisierung und Erfassung.

Die Filter oben auf der Seite „Analysefunktionen für Zahlungen“ gelten für alle Metriken, Diagramme und Tabellen auf der Seite.

Stripe verarbeitet Ihre Daten täglich von 0:00 Uhr UTC bis 23:59 Uhr UTC. Alle angezeigten Daten befinden sich in der Zeitzone UTC.

Der Currency-Filter ist standardmäßig auf Ihre Abrechnungswährung eingestellt. Um die Währung zu ändern, klicken Sie auf Währung () und wählen Sie die gewünschte Währung aus der Liste aus.

Sie können alle Daten herunterladen, die zur Erstellung des Berichts verwendet wurden. Um diese Analysen herunterzuladen, klicken Sie oben in jedem Diagramm auf herunterladen .

Downloads zeigen Zahlungen an, die den Filtern oben im Bericht entsprechen. Das Dialogfeld Download ist nur auf einen Währungsfilter (standardmäßig auf die Währung des Unternehmens) festgelegt.

Wenn Sie Sigma nutzen, können Sie Ihre Daten in Sigma anzeigen. Sie haben dann auch Zugriff auf die spezifischen Abfragen, die zum Erstellen der einzelnen Tabellen verwendet werden.

Metrikdefinitionen

Sie können Ihre Analysefunktionen anhand von zwei Metriken überprüfen: Erfolgsquote der Zahlungen oder Autorisierungsquote.

Quote erfolgreicher Zahlungen

Die Zahlungserfolgsquote misst alle erfolgreichen Zahlungsversuche in allen Phasen des Zahlungsvorgangs: Während der 3D Secure-Authentifizierung, Blockierungen durch Stripe oder Radar sowie Autorisierungen durch das Kartennetzwerks. Es handelt sich hierbei um die Anzahl der vom Kartennetzwerk autorisierten Zahlungen geteilt durch die Anzahl der über Stripe eingereichten eindeutigen Zahlungsversuche. Wir erfassen alle Zahlungsversuche mit Ausnahme ungültiger API-Aufrufe.

Autorisierungsquote

Die Netzwerk-Autorisierungsrate misst erfolgreiche Zahlungsversuche, die bei den Kartennetzwerken eingehen. Es handelt sich dabei um die Anzahl der vom Kartenaussteller autorisierten Zahlungen, geteilt durch die Anzahl der eindeutigen Zahlungsversuche, die zur Autorisierung an das Kartennetzwerk gesendet werden. Wir berücksichtigen keine ungültigen API-Aufrufe, Zahlungen, bei denen die 3D Secure-Authentifizierung fehlschlägt, und keine blockierte Zahlungen im Nenner, da diese Fehler auftreten, bevor Stripe die Autorisierungsanfrage an den Aussteller sendet.

Vergleichstabelle

Die folgende Tabelle zeigt, welche Arten von Zahlungsversuchen in den beiden Metriken enthalten sind.

Beispielrechnungen

Nachfolgend finden Sie ein Beispiel für die Berechnung der Autorisierungsquote für die Autorisierungsquote und die Erfolgsquote der Zahlung.

Deduplizierte Quote im Vergleich zu der Rate der Rohdaten

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 mit deduplizierter Quote und der Rate der Rohdaten.

Wenn Sie sich die deduplizierten Raten ansehen, werden Sie möglicherweise einen vorübergehenden Rückgang Ihrer Erfolgs- oder Autorisierungsquoten im letzten Monat feststellen, wenn noch nicht alle Zahlungsversuche wiederholt wurden. Standardmäßig ist der Bericht auf Dedupliziert eingestellt, da dies genauer darstellt, wie viele eindeutige Käufe letztendlich autorisiert werden. Um auch die wiederholten Versuche einzubeziehen, wechseln Sie zu den Rohdaten.

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.

So erkennt Stripe Wiederholungsversuche

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.

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

When a payment request is submitted to the card issuer, they use automated systems and models to determine whether to authorize it. If the issuer declines a payment, Stripe shares the reason the issuer gave for the decline. In some cases, the issuer provides specific reasons for the decline with a decline code. However, many payments are categorized into generic declines (the most common of which is do_not_honor). Card issuers can only discuss the specifics with their cardholders, not with you or Stripe, for privacy and security.

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.
• Incorrect number, incorrect CVC, and other incorrect card information responses: The customer has entered incorrect card information or card information that’s no longer valid. Make sure you have automatic card updates enabled. Contact the customer through multiple channels, such as email, text messages, or in-app notifications to re-enter their payment details or contact their card issuer if problems persist. Otherwise, try a different payment method.
• 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.
• Lost card or Stolen card: The customer has reported the card as either lost or stolen. Retries won’t be successful, and the customer should contact their card issuer for more information. Don’t report the specific reason to the customer in case the legitimate cardholder isn’t the one attempting the purchase.

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.

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.