Zahlungssicherheit und Nachweis

Bedienelemente enthalten

• Nur Server-to-Server-Credentials mit hoher Entropie und separate Zahlungsberechtigungen.
• Dauerhaft gespeicherte Zahlungsabsicht vor jeder externen Zahlungsinitiierung.
• Profil, Begünstigter, Konzept, Betrag und Institution werden vom Server festgelegt und validiert.
• Verschlüsselter sensibler Zustand; token des Widgets, der mit Unternehmen, Absicht, Ablaufdatum und Herkunft verknüpft ist, nur als Hash erhalten.
• Deterministische Kennungen der Initiierungsversuche und Fencing, um nach einem mehrdeutigen Ergebnis eine automatische erneute Initiierung zu verhindern.
• Dedizierter Callback, einmalige Verarbeitung, optimistische Versionskontrolle und Lease.
• Zensiertes Audit: enthält niemals Zugangsschlüssel, vollständige IBAN , IP, Rückrufe, vollständige Antworten oder undurchsichtigen Status.
• Ausdrücklich erlaubte Ziele und Weiterleitungen, mit HTTPS, maximalen Zeiten und begrenzten Antworten.
• Widget-Messaging mit exaktem Ursprung, event.source Validierung und versioniertem Schema.

Integration der Sandbox

Fragen Sie Wealth Reader:

1. einen privaten Zugangscode, der für Zahlungen und das erforderliche Profil autorisiert ist;
2. die genaue HTTPS Quelle, die das Widget hosten wird;
3. die vereinbarten Mengen- und Frequenzgrenzen;
4. Zugang zum Sandbox-Modus, der kein Geld bewegt.

Fragen Sie immer profile-institutions ab; in Sandbox wird nur eine simulierte Institution zurückgegeben. Erstellen Sie die Absicht mit expected_mode: "mock" und überprüfen Sie, dass die Bestätigung der Antwort auch mock anzeigt, bevor Sie die token an den Browser ausliefern.

Versuchen Sie zumindest:

• Wiederholung der Schöpfung mit demselben Schlüssel und Konflikt mit einem anderen Körper;
• veränderte Institution oder veränderter Modus;
• token abgelaufen und Herkunft nicht erlaubt;
• Popup gesperrt und zurück SCA;
• ausstehende Zwischenstatus, Abstimmung und Abschluss des Widgets;
• Bestätigung erst nach Erhalt payment_status: settled.

Echte Aktivierung anfordern

Bestätigen Sie vor einem Cash-Test mit Wealth Reader:

• dass die Institution in der Vorkonsultation für ihren Zugangscode erscheint;
• dass das Profil und seine Version genehmigt werden;
• dass Ursprung, callback und Fluss SCA von Ende zu Ende validiert wurden;
• dass es Begrenzungen für Menge, Häufigkeit, Abstimmung und Notfalldeaktivierung gibt;
• dass eine autorisierte Person für den Mindesttest verantwortlich ist.

Das Quellkonto kann für eine Institution erforderlich sein, in diesem Fall wird es vom Widget während der Autorisierung angefordert. Die Netzwerkadresse des Nutzers wird an der kontrollierten Grenze des APIabgeleitet; der Kunde sollte sie nicht einreichen. Weder diese Daten noch die IBAN des Schuldners werden bei Ereignissen offengelegt.

Die Sequenz mit curl bereitet die Absicht vor und fragt sie ab, vollendet jedoch die Bankauthentifizierung nicht. Der Nutzer muss im Bankbrowser oder der App weitermachen.

Die Profilaktivierung erfordert drei unabhängige, exakt festgelegte Bereitstellungskontrollen: WR_PAYMENTS_CRUZ_ROJA_PROFILE_ENABLED=1, WR_PAYMENTS_CRUZ_ROJA_PROFILE_VERSION=2026-09-04 und die Aufnahme des zum Zugangsschlüssel gehörenden Unternehmens in WR_PAYMENTS_CRUZ_ROJA_COMPANY_IDS. Diese Werte ersetzen weder die Zahlungsberechtigung noch aktivieren sie allein ein reales Institut.

Der derzeit veröffentlichte Vertrag markiert psuIp als ungenutzt, aber historische Tests des Connectors erforderten ihn. Wealth Reader hält die Aktivierung gesperrt, bis die Zielbereitstellung durch einen genehmigten End-to-End- und Optionstest sowohl das genaue Feld als auch die vertrauenswürdige Proxy-Policy verifiziert wurde. Sie sollte nicht mit beliebigen weitergeleiteten Headern aktiviert werden oder davon ausgehen, dass die veröffentlichte Anweisung historisches Verhalten widerspiegelt.

Private DNS-Auflösung und TLS-Beendigung für den internen Dienst hängen von jeder Bereitstellung ab: Dieses SDK setzt nicht voraus, dass sie existieren oder erreichbar sind. Sie müssen von der API Laufzeit aus überprüft werden, bevor ausgehende Verbindungen aktiviert oder neue Absichten akzeptiert werden.

Was man nicht tun sollte

• Senden Sie den API -Schlüssel, den vollständigen Begünstigten oder interne Daten an den Browser.
• Eine Institution erfinden, die nicht durch die Vorkonsultation zurückgereicht wurde.
• Wiederhole automatisch einen mehrdeutigen Anfang.
• Zeichnen Sie IBAN, Netzwerkadresse, callback oder vollständige Bankantwort auf.
• Interpretiere das Ende der Interaktion als endgültige Ausführung der Zahlung.
• Wiederverwenden Sie Bankaggregationsrouten, Token oder Rückrufe.