Eine Zahlungstransaktion mit Web Payments beginnt mit der Erkennung deiner Zahlungs-App. Hier erfährst du, wie du eine Zahlungsmethode einrichtest und deine Zahlungs-App für Händler und Kunden bereitstellst, damit sie Zahlungen vornehmen können.
Veröffentlicht: 27. September 2017, zuletzt aktualisiert: 16. Oktober 2026
Damit eine Zahlungs-App mit der Payment Request API verwendet werden kann, muss sie mit einer Kennung für die Zahlungsmethode verknüpft sein. Händler, die eine Zahlungs-App einbinden möchten, verwenden die Kennung der Zahlungsmethode, um dies dem Browser mitzuteilen. In diesem Artikel wird erläutert, wie die Erkennung von Zahlungs-Apps funktioniert und wie du deine Zahlungs-App so konfigurierst, dass sie von einem Browser richtig erkannt und aufgerufen wird.
Wenn du mit Webzahlungen noch nicht vertraut bist, lies zuerst die Übersicht über Webzahlungen.
Arten von Zahlungs-Apps
Eine Zahlungsmethode kann von einer Android-Zahlungs-App, einer webbasierten Zahlungs-App oder von beiden unterstützt werden:
- Android-Zahlungs-App:Eine installierte App, die Chrome mit einem Android-Intent startet. Chrome überprüft den Paketnamen und das Signaturzertifikat der App.
- Webbasierte Zahlungs-App: Ein Service Worker, den Chrome in einem modalen Fenster startet. Nutzer müssen nichts installieren.
Android-Zahlungs-Apps sind in Chrome für Android und in WebView verfügbar. Webbasierte Zahlungs-Apps sind in Chrome auf allen Plattformen verfügbar, aber nicht in WebView.
Wenn beide App-Typen für eine Zahlungsmethode verfügbar sind und in deinem Web-App-Manifest prefer_related_applications auf true gesetzt ist, blendet Chrome deine webbasierte Zahlungs-App aus. Andernfalls sehen Nutzer möglicherweise beide in der Benutzeroberfläche für Zahlungsanfragen und können zwischen ihnen wählen.
Unterstützte Browser
Web Payments besteht aus verschiedenen Technologien und der Supportstatus hängt vom Browser ab.
Wie ein Browser eine Zahlungs-App erkennt
Jede Zahlungs-App muss Folgendes bieten:
- URL-basierte Kennung der Zahlungsmethode
- Manifest der Zahlungsmethode (außer wenn die Kennung der Zahlungsmethode von einem Drittanbieter bereitgestellt wird)
- Web-App-Manifest
Der Erkennungsprozess beginnt, wenn ein Händler eine Transaktion initiiert:
- Der Browser sendet eine Anfrage an die URL der Zahlungsmethoden-ID und ruft das Zahlungsmethoden-Manifest ab.
- Der Browser ermittelt die URL des Web-App-Manifests aus dem Manifest der Zahlungsmethode und ruft das Web-App-Manifest ab.
- Der Browser bestimmt anhand des Web-App-Manifests, ob die Zahlungs-App des Betriebssystems oder die webbasierte Zahlungs-App gestartet werden soll.
In den nächsten Abschnitten wird ausführlich erläutert, wie Sie Ihre eigene Zahlungsmethode einrichten, damit Browser sie finden können.
Schritt 1: Kennung der Zahlungsmethode angeben
Eine Zahlungsmethoden-ID ist ein URL-basierter String. Die Kennung von Google Pay ist beispielsweise https://google.com/pay. Entwickler von Zahlungs-Apps können eine beliebige URL als Kennung für die Zahlungsmethode auswählen, solange sie die Kontrolle darüber haben und beliebige Inhalte und HTTP-Header bereitstellen können. In diesem Artikel verwenden wir https://bobbucks.dev/pay als Kennung für die Zahlungsmethode.
So verwenden Händler die Kennung der Zahlungsmethode
Ein PaymentRequest-Objekt wird mit einer Liste von Zahlungsmethoden-IDs erstellt, die Zahlungs-Apps identifizieren, die ein Händler akzeptiert. Zahlungsmethoden-IDs werden als Wert für das Attribut supportedMethods festgelegt. Beispiel:
[merchant] requests payment:
const request = new PaymentRequest([{
supportedMethods: 'https://bobbucks.dev/pay'
}], {
total: {
label: 'total',
amount: { value: '10', currency: 'USD' }
}
});
Schritt 2: Manifest der Zahlungsmethode bereitstellen
Ein Manifest für Zahlungsmethoden ist eine JSON-Datei, in der definiert wird, welche Zahlungs-App diese Zahlungsmethode verwenden kann.
Manifest der Zahlungsmethode bereitstellen
Wenn ein Händler eine Zahlungstransaktion initiiert, sendet der Browser eine HTTP-HEAD-Anfrage an die URL der Zahlungsmethoden-ID. Die URL der Zahlungsmethoden-ID antwortet mit einem Link-HTTP-Header, der auf die URL verweist, unter der der Browser das Manifest der Zahlungsmethode abrufen kann.
Konfiguriere den Server der Zahlungsmethode so, dass er mit einem HTTP-Link-Header mit dem Attribut rel="payment-method-manifest" und der URL des Manifests der Zahlungsmethode antwortet. Wenn sich das Manifest beispielsweise unter https://bobbucks.dev/pay/payment-manifest.json befindet, enthält der Antwortheader Folgendes:
Link: <https://bobbucks.dev/pay/payment-manifest.json>; rel="payment-method-manifest"
Die URL kann ein voll qualifizierter Domainname oder ein relativer Pfad sein. Prüfen Sie https://bobbucks.dev/pay auf Netzwerkverkehr, um ein Beispiel zu sehen. Sie können auch einen curl-Befehl verwenden:
curl --include https://bobbucks.dev/pay
Der Browser sendet als Nächstes eine HTTP-GET-Anfrage an die URL des Manifests der Zahlungsmethode. Der Server antwortet mit dem Text des Manifests der Zahlungsmethode.
Ein Manifest für Zahlungsmethoden hat zwei Felder: default_applications und supported_origins.
| Property-Name | Beschreibung |
|---|---|
default_applications (erforderlich) |
Ein Array von URLs, die auf Web-App-Manifeste verweisen, in denen die Zahlungs-Apps gehostet werden. (Die URL kann relativ sein.) Dieses Array sollte auf das Entwicklungsmanifest, das Produktionsmanifest usw. verweisen. |
supported_origins |
Ein Array von URLs, die auf Ursprünge verweisen, die möglicherweise Zahlungs-Apps von Drittanbietern hosten, die dieselbe Zahlungsmethode implementieren. Eine Zahlungsmethode kann von mehreren Zahlungs-Apps implementiert werden. |
Eine Manifestdatei für Zahlungsmethoden sollte so aussehen:
[payment handler] /payment-manifest.json:
{
"default_applications": ["https://bobbucks.dev/manifest.json"],
"supported_origins": [
"https://alicepay.friendsofalice.example"
]
}
Wenn der Browser das Feld default_applications liest, findet er eine Liste mit Links zu Web-App-Manifesten unterstützter Zahlungs-Apps.
Schritt 3: Web-App-Manifest bereitstellen
Ein Web-App-Manifest wird verwendet, um eine Web-App zu definieren, wie der Name schon sagt. Es ist eine weit verbreitete Manifestdatei, mit der eine progressive Web-App (PWA) definiert wird.
Ein typisches Web-App-Manifest sieht so aus:
[payment handler] /manifest.json:
{
"name": "Pay with Bobpay",
"short_name": "Bobpay",
"description": "This is an example of the Payment Handler API.",
"icons": [
{
"src": "images/manifest/icon-192x192.png",
"sizes": "192x192",
"type": "image/png"
},
{
"src": "images/manifest/icon-512x512.png",
"sizes": "512x512",
"type": "image/png"
}
],
"serviceworker": {
"src": "service-worker.js",
"scope": "/",
"use_cache": false
},
"payment": {
"supported_delegations": ["shippingAddress", "payerName", "payerEmail", "payerPhone"]
},
"start_url": "/",
"display": "standalone",
"theme_color": "#3f51b5",
"background_color": "#3f51b5",
"prefer_related_applications": true,
"related_applications": [
{
"platform": "play",
"id": "com.example.android.samplepay",
"min_version": "1",
"fingerprints": [
{
"type": "sha256_cert",
"value": "4C:FC:14:C6:97:DE:66:4E:66:97:50:C0:24:CE:5F:27:00:92:EE:F3:7F:18:B3:DA:77:66:84:CD:9D:E9:D2:CB"
}
]
}
]
}
Chrome liest je nach Art der Zahlungs-App unterschiedliche Felder. Bei einer Android-Zahlungs-App liest Chrome nur related_applications. Bei einer webbasierten Zahlungs-App liest Chrome name, icons, serviceworker, payment und prefer_related_applications.
| Property-Name | Beschreibung |
|---|---|
name (erforderlich)
|
Wird als Name der Zahlungs-App verwendet. |
icons (erforderlich)
|
Wird als Symbol für die Zahlungs-App verwendet. Diese Symbole werden nur von Chrome verwendet. Andere Browser können sie als Fallback-Symbole verwenden, wenn du sie nicht als Teil des Zahlungsmittels angibst. |
serviceworker
|
Nur webbasierte Zahlungs-Apps. Definiert den Service Worker, der als Zahlungs-App ausgeführt wird. |
serviceworker.src |
Die URL, von der das Service Worker-Script heruntergeladen werden soll. |
serviceworker.scope |
Ein String, der eine URL darstellt, die den Registrierungsbereich eines Service Workers definiert. |
serviceworker.use_cache |
Gibt an, ob der Browser seinen HTTP-Cache beim Abrufen des Service Worker-Skripts verwenden kann. |
payment.supported_delegations |
Nur webbasierte Zahlungs-Apps. Die Versand- und Kontaktdaten, die die Zahlungs-App bereitstellen kann: shippingAddress, payerName, payerEmail oder payerPhone. Android-Zahlungs-Apps deklarieren dies stattdessen in AndroidManifest.xml.
|
related_applications
|
Nur Android-Zahlungs-Apps. Identifiziert die App und ihr Signaturzertifikat. Weitere Informationen finden Sie im Entwicklerleitfaden für Android-Zahlungs-Apps. |
prefer_related_applications
|
Wird auf true gesetzt, um die webbasierte Zahlungs-App auszublenden, wenn die Android-Zahlungs-App installiert ist.
|
Das Attribut name des Web-App-Manifests wird als Name der Zahlungs-App verwendet, das Attribut icons als Symbol der Zahlungs-App.
Wie Chrome die zu startende Zahlungs-App bestimmt
Plattformspezifische Zahlungs-App starten
Damit die plattformspezifische Zahlungs-App gestartet werden kann, müssen die folgenden Bedingungen erfüllt sein:
- Das Feld
related_applicationswird im Web-App-Manifest angegeben und:- Die Paket-ID und die Signatur der installierten App stimmen überein, während die Mindestversion (
min_version) im Web-App-Manifest kleiner oder gleich der Version der installierten Anwendung ist.
- Die Paket-ID und die Signatur der installierten App stimmen überein, während die Mindestversion (
- Die plattformspezifische Zahlungs-App ist installiert und hat:
- Ein Intent-Filter von
org.chromium.intent.action.PAY. - Eine Zahlungsmethoden-ID, die als Wert für das Attribut
org.chromium.default_payment_method_nameangegeben ist.
- Ein Intent-Filter von
Weitere Informationen zur Einrichtung finden Sie im Entwicklerhandbuch für Android-Zahlungs-Apps.
[payment handler] /manifest.json
"prefer_related_applications": true,
"related_applications": [{
"platform": "play",
"id": "xyz.bobpay.app",
"min_version": "1",
"fingerprints": [{
"type": "sha256_cert",
"value": "92:5A:39:05:C5:B9:EA:BC:71:48:5F:F2:05:0A:1E:57:5F:23:40:E9:E3:87:14:EC:6D:A2:04:21:E0:FD:3B:D1"
}]
}]
Wenn prefer_related_applications den Wert true hat und die plattformspezifische Zahlungs-App verfügbar ist, blendet Chrome die webbasierte Zahlungs-App aus. Andernfalls sucht Chrome auch nach der webbasierten Zahlungs-App.
Webbasierte Zahlungs-App starten
Die webbasierte Zahlungs-App sollte im Feld serviceworker des Web-App-Manifests angegeben werden.
[payment handler] /manifest.json:
"serviceworker": {
"src": "payment-handler.js"
}
Der Browser startet die webbasierte Zahlungs-App, indem er ein paymentrequest-Ereignis an den Service Worker sendet. Der Service Worker muss nicht im Voraus registriert werden. Es kann Just-in-Time registriert werden.
Spezielle Optimierungen
Wie Browser die Payment Request API überspringen und eine Zahlungs-App direkt starten können
Wenn in Chrome die Methode show() von PaymentRequest aufgerufen wird, zeigt die Payment Request API eine vom Browser bereitgestellte Benutzeroberfläche an, die als „Payment Request UI“ bezeichnet wird. Über diese Benutzeroberfläche können Nutzer eine Zahlungs-App auswählen. Wenn sie in der Benutzeroberfläche für Zahlungsanfragen auf den Button Weiter klicken, wird die ausgewählte Zahlungs-App gestartet.
Wenn die Benutzeroberfläche für Zahlungsanfragen vor dem Start einer Zahlungs-App angezeigt wird, erhöht sich die Anzahl der Schritte, die ein Nutzer zum Ausführen einer Zahlung ausführen muss. Zur Optimierung des Prozesses kann der Browser die Bereitstellung dieser Informationen an Zahlungs-Apps delegieren und eine Zahlungs-App direkt starten, ohne die Benutzeroberfläche für Zahlungsanfragen anzuzeigen, wenn show() aufgerufen wird.
Damit eine Zahlungs-App direkt gestartet werden kann, müssen die folgenden Bedingungen erfüllt sein:
show()wird durch eine Nutzergeste ausgelöst, z. B. einen Mausklick.- Es gibt nur eine Zahlungs-App, die:
- Unterstützt die angeforderte Kennung der Zahlungsmethode.
- Unterstützt alle vom Händler angeforderten Versand- und Kontaktdaten.
Wann wird eine webbasierte Zahlungs-App Just-in-Time (JIT) registriert?
Webbasierte Zahlungs-Apps können gestartet werden, ohne dass der Nutzer die Website der Zahlungs-App explizit besucht und den Service Worker registriert hat. Der Service Worker kann Just-in-Time registriert werden, wenn der Nutzer sich für die Zahlung mit der webbasierten Zahlungs-App entscheidet. Es gibt zwei Varianten für den Zeitpunkt der Registrierung:
- Wenn dem Nutzer die Payment Request UI angezeigt wird, wird die App Just-in-Time registriert und gestartet, wenn der Nutzer auf Weiter klickt.
- Wenn die Payment Request API übersprungen wird, wird die Zahlungs-App Just-in-Time registriert und direkt gestartet. Wenn die Payment Request API-Benutzeroberfläche übersprungen wird, um eine Just-in-Time-registrierte App zu starten, ist eine Nutzergeste erforderlich. Dadurch wird die unerwartete Registrierung von ursprungsübergreifenden Service Workern verhindert.
Webbasierte Zahlungs-App erstellen
Wenn der Händler show() aufruft, sendet Chrome ein paymentrequest-Ereignis an deinen Service Worker. Rufe openWindow() in respondWith() auf, um die Benutzeroberfläche für die Zahlung anzuzeigen, und löse dann die Zahlung mit der Zahlungsantwort auf.
Die vollständige API finden Sie unter Web-Based Payment Handler API auf MDN.