Nur serverseitig
Ein Produktionsschlüssel in einer Web- oder Mobile-App ist ein öffentlicher Schlüssel: Ausgelieferter Code ist lesbar, und Minifizierung ist keine Verschlüsselung. Rufen Sie die API von Ihrem Server aus auf.
Developers
Authentifizierung
Wie der Preisstellungs-Endpunkt heute geschützt ist, wie Schlüssel ausgegeben werden und die Handhabungsregeln, die das klassische Ergebnis vermeiden: ein Produktionsschlüssel in einem öffentlichen Repository.
Heute
Der Preisstellungs-Endpunkt ist offen und erfordert keinen Schlüssel. Die Wahl ist vertretbar: Ein Angebot liest oder schreibt keine persönlichen Daten, und eine Integration muss in der Lage sein, einen Preis anzuzeigen, bevor ein Konto existiert.
Was noch nicht eingerichtet ist
Auf diesem Endpunkt wird heute keine Ratenbegrenzung angewendet. Wir schreiben das lieber, als eine Kontingenttabelle anzuzeigen, die nicht durchgesetzt wird: An dem Tag, an dem die Grenze existiert, wird sie hier mit ihren Werten, ihren Antwort-Headern und dem Code veröffentlicht, der bei Überschreitung zurückgegeben wird.
Schlüssel, sobald sie ausgegeben sind
Ein Schlüssel trägt seine Umgebung in seinem Präfix. Ein Testschlüssel, der in der Produktion funktioniert hat, wäre ein Designfehler: Er ermöglicht die echte Überweisung, von der Sie dachten, Sie simulieren sie.
Authorization: Bearer sk_live_9f2c4b1e8a7d3f60c5b2a1e9d8c7b6a5| Präfix | Umgebung | Was sie ermöglicht |
|---|---|---|
sk_test_ | Sandbox | Jede Operation mit simulierten Daten. Keine echte Geldbewegung, kein Aufruf eines Zahlungsinstituts. Die Latenzen der Zahlungswege werden simuliert, sodass Ihre Tests dieselben Wartezeiten wie in der Produktion haben. |
sk_live_ | Produktion | Echte Operationen. Mit diesem Schlüssel erstellte Aufträge bewegen Geld: Er darf Ihren Server niemals verlassen. |
whsec_ | Beide | Webhook-Signaturschlüssel. Er wird nie zum Aufrufen der API verwendet: Er dient nur zur Überprüfung, dass das, was Sie empfangen, wirklich von uns stammt. |
Handhabungsregeln
Keine davon ist originell. Alle werden regelmäßig gebrochen, und so leaken Schlüssel.
Nie in einer URL
Als Abfrageparameter landet ein Schlüssel in Server-Logs, Referrer-Headern und Browser-Verlauf. Dafür gibt es den Authorization-Header.
Ein Schlüssel pro Integration
Ein Schlüssel, der von drei Diensten gemeinsam genutzt wird, kann nicht widerrufen werden, ohne alle drei zu beeinträchtigen. Ein Schlüssel pro Verwendung macht den Widerruf schmerzlos.
Sofortiger Widerruf bei jedem Zweifel
Ein Schlüssel, der versehentlich in ein Repository gepusht wurde, selbst in ein privates, selbst wenn er danach gelöscht wird, ist kompromittiert: Die Historie bewahrt ihn auf, und Crawler lesen öffentliche Repositories innerhalb von Minuten.
Rotation ohne Ausfallzeit
Zwei gleichzeitig gültige Schlüssel ermöglichen eine Rotation ohne Verfügbarkeitsfenster.
- 1.Stellen Sie einen zweiten Schlüssel aus. Beide sind gleichzeitig gültig.
- 2.Setzen Sie den neuen Schlüssel auf Ihren Servern ein, einen nach dem anderen.
- 3.Überprüfen Sie, dass der neue Schlüssel Datenverkehr erhält und der alte nicht.
- 4.Widerrufen Sie den alten. Der Widerruf ist sofort wirksam, ohne Gnadenfrist.
Was wir niemals tun werden
- Wir werden Sie niemals per E-Mail, Chat oder Telefon nach Ihrem Schlüssel fragen. Der Support benötigt ihn nicht: Er arbeitet mit der Schlüssel-ID, nicht mit dem Geheimnis.
- Wir zeigen einen geheimen Schlüssel niemals zweimal an. Er ist bei der Erstellung sichtbar, danach nur seine ID und die letzten vier Zeichen.
- Wir senden Schlüssel nicht per E-Mail. E-Mails durchlaufen zu viele Parteien und werden von ihnen aufbewahrt.