Signatur
Beschreibung
Der Konstruktor CanMakePaymentEvent() gehört zur Payment Handler API. Er erzeugt ein Ereignisobjekt vom Typ CanMakePaymentEvent, das von ExtendableEvent erbt. Im normalen Betrieb erzeugt der Browser dieses Ereignis selbst und löst es im Service Worker einer Zahlungs-App aus, sobald eine Händlerseite new PaymentRequest(...) mit einer passenden Zahlungsmethode aufruft. Mit event.respondWith() antwortet der Handler dann, ob er bereit ist, die Zahlung zu übernehmen.
Selbst musst du den Konstruktor nur selten aufrufen. Er ist vor allem für Unit-Tests und zum Simulieren gedacht: Du erzeugst ein synthetisches Ereignis und prüfst damit die Logik deines canmakepayment-Listeners, ohne einen echten Zahlungsablauf anzustoßen.
Der Konstruktor steht nur im ServiceWorkerGlobalScope zur Verfügung, also nicht im Fensterkontext einer normalen Webseite. Ältere Fassungen der Spezifikation kannten zusätzliche Init-Felder wie topOrigin, paymentRequestOrigin, methodData und modifiers. Aus Datenschutzgründen wurden sie entfernt, und aktuelle Chromium-Versionen liefern sie nicht mehr.
Parameter
| Name | Typ | Default | Beschreibung |
|---|---|---|---|
| $type Pflicht | string | Name des Ereignisses. Für echte Zahlungs-Handler ist das immer "canmakepayment". |
|
| $options | Object (ExtendableEventInit) | {} | Optionales Init-Objekt mit den üblichen EventInit-Feldern bubbles, cancelable und composed (alle standardmäßig false). Veraltete Felder wie topOrigin, paymentRequestOrigin und methodData werden nicht mehr unterstützt. |
Rückgabewert
CanMakePaymentEvent. Mit new erzeugte Ereignisse haben isTrusted === false.Beispiele
Synthetisches Ereignis im Service Worker erzeugen
// sw.js – läuft im ServiceWorkerGlobalScope
const event = new CanMakePaymentEvent('canmakepayment');
console.log(event.type); // Ereignisname
console.log(event instanceof ExtendableEvent); // erbt von ExtendableEvent
console.log(event.isTrusted); // synthetisch, nicht vom Browser
Typische Nutzung: auf canmakepayment reagieren
// sw.js einer Zahlungs-App
const isUserLoggedIn = async () => {
const cache = await caches.open('session');
return Boolean(await cache.match('/session-token'));
};
self.addEventListener('canmakepayment', (event) => {
// Promise<boolean>: true = Handler kann die Zahlung übernehmen
event.respondWith(isUserLoggedIn());
});
Alternative über die on-Property
// sw.js
self.oncanmakepayment = (event) => {
// Immer bereit – z. B. für eine Demo-Zahlungsmethode
event.respondWith(Promise.resolve(true));
};
Handler-Logik testen, ohne respondWith auszulösen
// sw.js – Entscheidungslogik ausgelagert und damit testbar
const decide = async (event) => event.type === 'canmakepayment';
const testEvent = new CanMakePaymentEvent('canmakepayment');
decide(testEvent).then((ok) => console.log('Kann zahlen:', ok));
// Wichtig · Fallstricke
- Nur im Service Worker: Im Fensterkontext ist
CanMakePaymentEventnicht definiert. Ein Aufruf dort löst einenReferenceErroraus. - Synthetische Ereignisse: Ruft man
respondWith()auf einem selbst erzeugten Ereignis (isTrusted === false) auf, wirft der Browser einenInvalidStateError. Die Entscheidungslogik lagert man für Tests deshalb besser in eine eigene Funktion aus. - Browser-Unterstützung: Die Schnittstelle ist experimentell und nur in Chromium-Browsern verfügbar. Firefox und Safari unterstützen die Payment Handler API nicht. Vor der Nutzung sollte man mit
'CanMakePaymentEvent' in selfprüfen, ob sie vorhanden ist. - Datenschutz: Die früheren Felder
topOrigin,paymentRequestOrigin,methodDataundmodifierswurden entfernt, damit Zahlungs-Apps Nutzer nicht über verschiedene Websites hinweg verfolgen können. Verlass dich nicht auf diese Felder. - Der Browser löst
canmakepaymentnur aus, wenn die Zahlungs-App korrekt installiert ist, also mit Service Worker und Web-App-Manifest bzw. Zahlungsmethoden-Manifest.