// stack · schnittstelle
Apple Pay ist eine Bezahlmethode — kein eigener Zahlungsdienstleister. Was aus dem Wallet kommt, ist die Bestätigung per Face ID oder Touch ID und die dort hinterlegten Karten- und Adressdaten. Abgewickelt wird die Zahlung weiterhin über den Zahlungsdienstleister, bei siteway in der Regel über Stripe. Diese Seite beschreibt, was der Button technisch voraussetzt und wie wir ihn in eine Bezahlstrecke einbauen, die auch ohne ihn vollständig funktioniert.
// definition
Apple Pay ist eine Bezahlmethode von Apple. Die Karte liegt im Wallet auf dem Gerät, bestätigt wird die Zahlung dort — per Face ID oder Touch ID. Für Websites stellt Apple dafür zwei JavaScript-Schnittstellen bereit, die Apple Pay JS API und die Payment Request API. Beide führen zum selben Ergebnis: einem Bezahlblatt, das das Betriebssystem einblendet, und einer Bestätigung, die nicht im Browser stattfindet, sondern auf dem Gerät.
Was dabei technisch übergeben wird, ist keine Kartennummer, sondern ein verschlüsseltes Zahlungs-Token. Die eigentliche Karte liegt laut Apple als gerätespezifische Device Account Number im Secure Element des Geräts; in der Datenschutzerklärung zu Apple Pay hält Apple ausdrücklich fest, dass die tatsächliche Kartennummer nicht an den Händler weitergegeben wird.
Und hier liegt der Punkt, der in Gesprächen am häufigsten verrutscht: Apple Pay ist kein eigener Zahlungsdienstleister. Es ersetzt kein Bezahlsystem, es setzt eines voraus. Die Zahlung wird über den Anbieter abgewickelt, der ohnehin im Einsatz ist — bei uns in der Regel Stripe, der Apple Pay in seiner Dokumentation als Zahlungsmethode vom Typ Wallet führt und dafür keine zusätzlichen Gebühren berechnet, sondern dieselbe Preisgestaltung wie bei anderen Kartentransaktionen ansetzt. Apple Pay steuert die Bestätigung und die hinterlegten Daten bei. Alles andere bleibt, wo es war.
// praxis
zusatz · nicht bedingung
Die Reihenfolge steht fest: erst der Zahlungsdienstleister, dann die Methode. Apple Pay legt sich auf eine Bezahlstrecke, die bereits funktioniert. Wer den Wallet-Button an den Anfang stellt, baut die Kasse um einen Knopf herum — und steht ohne Strecke da, sobald der Knopf auf einem Gerät nicht erscheint. Wir bauen andersherum: Die Bezahlstrecke trägt allein, Apple Pay ist die Abkürzung darin.
Dann kommt die Verfügbarkeitsprüfung. Apple beschreibt dafür einen klaren Ablauf: prüfen, ob die Schnittstelle im Browser überhaupt existiert, und danach, ob auf dem Gerät gezahlt werden kann und eine Karte im Wallet liegt. Die neuere Prüfung liefert dazu vier Zustände — Karte vorhanden, Zustand unbekannt, keine Karte hinterlegt, Gerät nicht unterstützt — und Apple leitet daraus ab, wie prominent der Button auftauchen darf. Genau das steuert bei uns die Anzeige: Kein Zustand, kein Button.
Der Button selbst wird nicht nachgebaut. Apple stellt ihn als eigenes Element <apple-pay-button> bereit, geladen über ein Skript von Apples Content Delivery Network; Stil, Typ und Sprache setzt man als Attribute, Größe und Eckenradius über CSS-Variablen wie --apple-pay-button-height. Für Höhe und Breite nennt die Dokumentation Mindestwerte, unter die der Button nicht rendert. Wir fügen ihn ins Layout ein, statt eine Nachbildung zu bauen, die bei der nächsten Änderung an Apples Vorgaben aus dem Rahmen fällt.
Der Zahlungsvorgang läuft serverseitig. Die Merchant-Validierung, mit der sich der Händler gegenüber den Apple-Pay-Servern ausweist, gehört ausdrücklich nicht in den Browser — Apple schreibt das in der Dokumentation so hin, und die zurückgegebene Sitzung ist einmalig verwendbar und läuft nach fünf Minuten ab. Der Endpunkt dafür liegt also im Backend, mit den Zugangsdaten in der Server-Konfiguration. Wer Stripe einsetzt, bekommt diesen Teil vom Anbieter übernommen: Stripe erledigt die Händlervalidierung einschließlich Merchant-ID und Zertifikatsanforderung und weist in seiner Dokumentation ausdrücklich darauf hin, dafür nicht dem Verfahren aus der Apple-Dokumentation zu folgen.
Und schließlich das, was in Angeboten gern fehlt: der Abbruch. Jemand schließt das Bezahlblatt, die Karte wird abgelehnt, die Netzverbindung bricht weg. Dann muss die Seite in den normalen Ablauf zurückführen, mit vollem Warenkorb und ohne doppelte Buchung. Dazu gehört die Regel, dass das Bezahlblatt nur aus einer echten Nutzergeste heraus geöffnet wird — Apple verlangt das, und Stripe beschreibt in seiner Dokumentation, was das für den Aufbau des Event-Handlers bedeutet. Wie wir solche Strecken insgesamt bauen, steht in der Leistung Schnittstellenentwicklung.
// technik · 6 details
belegt aus der doku
Was hier steht, stammt aus Apples Entwicklerdokumentation zu Apple Pay on the Web und aus der Dokumentation von Stripe — Begriffe, Pfade und Abläufe im Original. Geräte- und Browserversionen nennen wir bewusst nicht: Sie ändern sich, und die Verfügbarkeitsprüfung im Browser beantwortet die Frage ohnehin zuverlässiger als eine Tabelle.
// d-01zugang
Apple verlangt eine Merchant-ID, ein Payment-Processing-Zertifikat zum Verschlüsseln der Zahlungsdaten und ein Merchant-Identity-Zertifikat für die Sitzungen mit den Apple-Pay-Servern — Letzteres ausdrücklich nur im Web. Die Merchant-ID läuft nicht ab, die Zertifikate und die Domain-Verifizierung schon. Bei Stripe übernimmt der Anbieter diesen Teil.
zweck: identität
// d-02verfügbarkeit
Zuerst wird geprüft, ob die Apple-Pay-Klasse im Browser existiert. Danach beantwortet die Prüfung, ob das Gerät zahlen kann und eine Karte im Wallet liegt. Die neuere Variante liefert vier Zustände: Karte vorhanden, Zustand unbekannt, keine Karte hinterlegt, Gerät nicht unterstützt — daraus folgt, ob und wie prominent der Button erscheint.
zweck: anzeige steuern
// d-03button
Apple liefert den Button als eigenes Element <apple-pay-button>, geladen über ein Skript von Apples CDN. Stil, Typ und Sprache kommen als Attribute, Breite, Höhe, Eckenradius und Innenabstand über CSS-Variablen. Für Höhe und Breite gibt Apple Mindestwerte an — kleiner rendert der Button nicht, egal was im Stylesheet steht.
zweck: einstieg
// d-04sitzung
Sobald das Bezahlblatt erscheint, fragt Apple nach der Identität des Händlers und übergibt eine Validierungs-URL. Die Anfrage dorthin gehört laut Apple auf den Server, nie in den Browser. Zurück kommt ein undurchsichtiges Sitzungsobjekt, das genau einmal verwendbar ist und fünf Minuten nach Erstellung abläuft.
zweck: serverseitig
// d-05daten
Nach der Bestätigung liefert Apple Pay ein Token mit den Zahlungsdaten. Apple hält dazu fest: Die Daten im Token sind verschlüsselt, Rechnungs- und Versandkontaktdaten sind es nicht. Entschlüsselt wird mit dem privaten Schlüssel zum Payment-Processing-Zertifikat — in der Praxis beim Zahlungsdienstleister, nicht auf dem Webserver.
zweck: übergabe
// d-06anfrage
Die Anfrage beschreibt den Kauf: Händlerangaben, unterstützte Kartennetze, Einzelposten, Summe, Währung sowie Rechnungs- und Lieferkontakt. Daneben kennt Apple eigene Objekte für wiederkehrende Zahlungen, für automatisches Aufladen und für später fällige Zahlungen — je Anfrage darf allerdings nur eine dieser Varianten gesetzt sein.
zweck: was gezahlt wird
Sichtbar wird davon wenig — und das ist der Punkt. Auf einem unterstützten Gerät mit hinterlegter Karte steht der Wallet-Button dort, wo die Entscheidung fällt: im Warenkorb, auf der Bezahlseite, je nach Fall auch schon an der Produktseite. Ein Tippen öffnet das Bezahlblatt, Face ID oder Touch ID bestätigen, die Bestellung ist abgeschlossen. Adresse und Kartendaten kommen aus dem Wallet — auf dem Telefon fällt damit genau der Teil weg, an dem Bezahlvorgänge am häufigsten abbrechen.
Auf jedem anderen Gerät passiert dagegen etwas ebenso Wichtiges: nichts. Kein leerer Platzhalter, kein toter Knopf, keine Fehlermeldung — die reguläre Bezahlstrecke steht einfach da, als hätte es den Button nie gegeben. Das ist progressive Enhancement, wie wir es im Frontend durchgängig anwenden: Die Grundfunktion trägt allein, die Erweiterung kommt oben drauf, wenn die Umgebung sie hergibt.
Beim Datenschutz lohnt der genaue Blick, weil hier mehrere Wege zusammenlaufen. Der Browser kontaktiert für die Verfügbarkeitsprüfung Apple-Server, dein Server spricht für die Merchant-Validierung mit den Apple-Pay-Servern, und das Zahlungs-Token geht an den Zahlungsdienstleister. Kontaktdaten aus dem Wallet gehen nur an die Website, soweit die Anfrage sie anfordert — also fordern wir nur an, was für Vertrag und Versand nötig ist. Zugangsdaten und Zertifikate liegen serverseitig, die Datenschutzerklärung benennt die beteiligten Dienste, und in welcher Form das dokumentiert gehört, klärst du mit deiner Rechtsberatung. Die technische Seite beschreiben wir im Stack unter Sicherheit & Datenschutz.
// integration
drei systeme · ein muster
Der Weg ist in jedem System derselbe, weil er nicht vom CMS abhängt, sondern von der Methode. Der Bezahl-Button erscheint nur dann, wenn Gerät und Browser Apple Pay unterstützen und eine Karte im Wallet hinterlegt ist — die Prüfung dafür läuft im Browser, bevor überhaupt etwas gerendert wird. Daraus folgt eine Anforderung an die Bezahlstrecke, die vor der ersten Zeile Code feststeht: Sie muss beide Fälle sauber darstellen. Mit Button ist er die naheliegende Wahl und steht sichtbar oben; ohne Button steht dort die reguläre Strecke, vollständig und ohne Lücke im Layout. Beide Zustände gehören ins Design, in die Tests und in die Abnahme — nicht nur der hübsche.
Der eigentliche Zahlungsvorgang läuft über den serverseitigen Endpunkt des Zahlungsdienstleisters. Im Frontend liegt nur, was im Frontend liegen darf: das Button-Element, die Verfügbarkeitsprüfung und der Aufruf, der das Bezahlblatt aus einer Nutzergeste heraus öffnet. Alles Weitere — Validierung der Händleridentität, Übergabe des Zahlungs-Tokens, Bestätigung der Zahlung — passiert im Backend, mit Zugangsdaten aus der Server-Konfiguration statt aus dem Repository. Was sich je System unterscheidet, ist damit nur die Frage, wo diese drei Stellen liegen: Template, Endpunkt, Zugangsdaten.
// cms-01typo3
In TYPO3 bauen wir die Anbindung als eigene Extension. Der Button und die Verfügbarkeitsprüfung sitzen im Fluid-Template der Bezahlseite, eingebunden über das Asset-Handling der Extension, damit das Skript nur dort geladen wird, wo tatsächlich bezahlt wird. Der serverseitige Endpunkt ist eine eigene Route mit Middleware oder ein Controller im Extbase-Kontext — dort laufen Merchant-Validierung und die Bestätigung der Zahlung beim Dienstleister. Die Zugangsdaten liegen als Umgebungsvariablen in der Server-Konfiguration und werden über die Extension-Konfiguration gelesen, nicht im TypoScript und nicht im Repository.
// cms-02wordpress
In WordPress entsteht die Anbindung als eigenes Plugin und nicht als Theme-Code — so überlebt sie einen Theme-Wechsel. Button und Verfügbarkeitsprüfung kommen über eine Template-Datei oder einen eigenen Block in die Bezahlseite, das Skript wird gezielt nur auf dieser Seite eingereiht. Der serverseitige Endpunkt ist eine eigene REST-Route des Plugins, die mit dem Zahlungsdienstleister spricht. Die Zugangsdaten stehen als Konstanten in der Server-Konfiguration statt in der Datenbank, damit sie beim Export der Inhalte nicht mitwandern.
// cms-03statamic
Statamic läuft auf Laravel, und das macht diesen Teil besonders geradlinig. Button und Verfügbarkeitsprüfung liegen im Antlers- oder Blade-Template der Bezahlseite. Der serverseitige Endpunkt ist eine Route plus Controller im Laravel-Unterbau, abgesichert über die üblichen Middleware-Schichten; von dort geht die Merchant-Validierung raus und die Zahlung wird beim Dienstleister bestätigt. Die Zugangsdaten liegen in der Umgebungsdatei außerhalb des Repositories und werden über die Konfiguration gelesen. Die Bezahlseite selbst bleibt vom Static Caching ausgenommen.
Ein Punkt gehört hierher, weil er nicht ins CMS fällt, sondern ins Deployment: Für Apple Pay im Web muss die Domain verifiziert werden. Apple lädt dafür eine Prüfdatei unter einem festgelegten Pfad — https://[DOMAIN]/.well-known/apple-developer-merchantid-domain-association — und vergleicht ihren Inhalt. Registriert und verifiziert werden müssen laut Apple alle Top-Level-Domains und Subdomains, auf denen der Button erscheint; Stripe weist ausdrücklich darauf hin, dass auch www eine Subdomain ist und mitregistriert gehört. Hinter einem Proxy oder einer Weiterleitung funktioniert die Prüfung nicht.
In der Praxis ist genau das die Stelle, an der Apple Pay still ausfällt. Die Datei wird vom nächsten Build überschrieben, landet nicht im Auslieferungsverzeichnis, wird durch eine Umleitungsregel abgefangen oder mit falschem Inhaltstyp ausgeliefert. Und weil die Verifizierung wie die Zertifikate abläuft, reicht es nicht, sie einmal abgehakt zu haben. Deshalb behandeln wir die Prüfdatei als Bestandteil des Deployments: fest im Auslieferungspfad, ausgenommen von Umleitungsregeln, nach jedem Deploy überprüft. Wie wir Deployments aufsetzen und was dabei automatisch mitläuft, steht im Stack unter Deployment & Betrieb.
// voraussetzungen
seite, domain & gerät
Die Liste ist kurz und lässt sich vor dem Projektstart abhaken. Drei Punkte liegen auf deiner Seite und sind planbar, einer liegt beim Publikum und lässt sich nur beantworten, nicht beeinflussen. Alle vier stehen so in der Dokumentation von Apple; Versionsnummern zu Geräten und Browsern lässt siteway bewusst weg, weil sie altern — die Prüfung im Browser beantwortet die Frage ohnehin für den konkreten Besuch.
// v-01transport
Alle Seiten, auf denen Apple Pay vorkommt, müssen über HTTPS ausgeliefert werden — die Domain braucht ein gültiges SSL-Zertifikat. Apple nennt dazu konkret TLS in Version 1.2 oder neuer, eine feste Liste zulässiger Cipher Suites und Server Name Indication auf allen Verbindungen. Für eine sauber aufgesetzte Website ist das kein Sonderaufwand, sondern der Normalzustand — geprüft gehört es trotzdem, bevor jemand den Button vermisst.
// v-02domain
Jede Top-Level-Domain und jede Subdomain, auf der der Apple-Pay-Button steht, muss bei Apple registriert und verifiziert sein — die Prüfdatei liegt dafür unter /.well-known/ auf der Domain. Apple hält fest, dass die Domains nicht hinter einem Proxy oder einer Weiterleitung liegen dürfen und für die Apple-Server erreichbar sein müssen. Auch Testumgebungen und die www-Variante gehören auf diese Liste.
prüfen: nach jedem deploy
// v-03abwicklung
Ohne Anbieter, der die Zahlung abwickelt, bleibt Apple Pay ein Knopf ohne Wirkung. Der Dienstleister entschlüsselt das Zahlungs-Token, bucht ab, erstattet zurück und bearbeitet strittige Fälle. Bei uns ist das in der Regel Stripe, das die Händlervalidierung gegenüber Apple übernimmt und für Apple Pay dieselbe Preisgestaltung wie für andere Kartentransaktionen ansetzt.
// v-04publikum
Auf Kundenseite braucht es ein Gerät und einen Browser, die die Methode unterstützen, und eine Karte im Wallet. Apple beschreibt Apple Pay auf iOS-Geräten mit Secure Element; am Mac wird die Zahlung über Touch ID oder ein gekoppeltes Apple-Gerät bestätigt. Ob all das im Einzelfall zutrifft, beantwortet die Verfügbarkeitsprüfung im Browser — deshalb steuert sie bei uns die Anzeige des Buttons.
// faq
Apple Pay ist eine Bezahlmethode von Apple. Die Karte liegt im Wallet auf dem Gerät, bestätigt wird die Zahlung dort per Face ID oder Touch ID. Für Websites stellt Apple laut seiner Entwicklerdokumentation zwei JavaScript-Schnittstellen bereit: die Apple Pay JS API und die Payment Request API. Beim Bezahlen bekommt der Händler ein verschlüsseltes Zahlungs-Token statt der Kartennummer; Apple beschreibt in seiner Datenschutzerklärung zu Apple Pay ausdrücklich, dass die tatsächliche Kartennummer nicht an den Händler weitergegeben wird.
Nein. Apple Pay ist eine Bezahlmethode, die über den Zahlungsdienstleister läuft, den du ohnehin einsetzt — bei uns in der Regel Stripe. Apple Pay steuert die Bestätigung im Wallet bei sowie die dort hinterlegten Karten- und Adressdaten. Der Geldfluss, die Abrechnung, Rückerstattungen und der Umgang mit strittigen Zahlungen bleiben beim Zahlungsdienstleister. Stripe führt Apple Pay in seiner Dokumentation entsprechend als Zahlungsmethode vom Typ Wallet und weist aus, dass für die Verarbeitung keine zusätzlichen Gebühren anfallen, sondern dieselbe Preisgestaltung wie bei anderen Kartentransaktionen gilt.
Vier Dinge, und drei davon liegen auf deiner Seite. Erstens: Alle Seiten, auf denen Apple Pay vorkommt, müssen über HTTPS ausgeliefert werden, mit gültigem SSL-Zertifikat und einem Server, der laut Apple TLS in Version 1.2 oder neuer sowie die dort gelisteten Cipher Suites unterstützt; Server Name Indication verlangt Apple auf allen Verbindungen. Zweitens: Jede Domain und Subdomain, auf der der Apple-Pay-Button erscheint, muss bei Apple registriert und verifiziert sein — hinter einem Proxy oder einer Weiterleitung geht das laut Apple nicht. Drittens: ein Zahlungsdienstleister, der die Methode abwickelt. Und viertens auf Kundenseite: ein Gerät und ein Browser, die die Methode unterstützen, und eine Karte im Wallet.
Weil er nur erscheinen soll, wenn er auch funktioniert. Apple beschreibt dafür eine Prüfung im Browser: Erst wird geprüft, ob die Schnittstelle überhaupt existiert, dann, ob auf dem Gerät gezahlt werden kann und ob eine Karte im Wallet liegt. Die neuere Prüfung liefert dafür vier Zustände — Karte verfügbar, Zustand unbekannt, keine Karte hinterlegt, Gerät nicht unterstützt — und Apple leitet daraus ab, ob der Button prominent, normal oder gar nicht gezeigt wird. Für die Bezahlstrecke heißt das: Sie muss beide Fälle sauber darstellen, mit Button und ohne. Auf einem Windows-Rechner oder einem Android-Telefon sieht dieselbe Seite deshalb schlicht anders aus.
Apple muss bestätigt bekommen, dass die Domain wirklich zu dir gehört. Dafür wird eine Prüfdatei unter einem festgelegten Pfad ausgeliefert: https://[DOMAIN]/.well-known/apple-developer-merchantid-domain-association. Apple lädt die Datei von dort und vergleicht den Inhalt. Registriert und verifiziert werden müssen alle Top-Level-Domains und Subdomains, auf denen der Button steht, also auch www. Genau hier klemmt es in der Praxis am häufigsten: Die Datei fehlt nach einem Deployment, liegt hinter einer Weiterleitung, wird vom Server mit falschem Typ ausgeliefert oder verschwindet beim nächsten Build. Deshalb behandeln wir sie als Teil des Deployments und nicht als einmalige Handarbeit. Apple weist außerdem darauf hin, dass die Domain-Verifizierung wie die Zertifikate abläuft und erneuert werden muss.
Der Punkt ist nicht Magie, sondern Tipparbeit. Karten- und Adressdaten liegen bereits im Wallet und werden auf Wunsch als Rechnungs- und Lieferkontakt an die Bezahlseite übergeben; bestätigt wird per Face ID oder Touch ID statt über ein Formular. Auf einem Telefon entfällt damit genau der Teil, an dem Bezahlvorgänge am häufigsten abbrechen: das Abtippen einer sechzehnstelligen Kartennummer mit Prüfziffer und Rechnungsadresse. Ob das bei deinem Publikum ins Gewicht fällt, zeigt der Anteil mobiler Zugriffe und nicht eine Zahl aus einer fremden Fallstudie.
Nach der Bestätigung liefert Apple Pay ein Zahlungs-Token. Apple beschreibt dazu klar: Die Daten im Token sind verschlüsselt, Rechnungs- und Versandkontaktdaten sind es nicht. Entschlüsseln kann das Token nur, wer den privaten Schlüssel zum Payment-Processing-Zertifikat hat — in der Praxis also der Zahlungsdienstleister. Dazu kommt die Merchant-Validierung, bei der dein Server mit den Apple-Pay-Servern spricht, und die Verfügbarkeitsprüfung im Browser, die Apple-Server kontaktiert. Für die Website bleibt daraus dieselbe Regel wie bei jeder anderen Bezahlmethode: nur die Felder anfordern, die für Vertrag und Versand nötig sind, Schlüssel und Zertifikate serverseitig halten und im Verzeichnis der Verarbeitungstätigkeiten sauber führen, wohin welche Daten gehen. Die rechtliche Bewertung gehört zu deiner Rechtsberatung, die technische Umsetzung zu uns.
Ja, und in allen drei Systemen nach demselben Muster. Im Template sitzen der Button und die Verfügbarkeitsprüfung, serverseitig sitzt der Endpunkt, der mit dem Zahlungsdienstleister spricht, und die Zugangsdaten liegen außerhalb des Repositories in der Server-Konfiguration. In TYPO3 bauen wir dafür eine eigene Extension mit Fluid-Template für die Bezahlseite und einer eigenen Route für den serverseitigen Endpunkt. In WordPress entsteht ein eigenes Plugin mit eigener REST-Route, damit die Anbindung einen Theme-Wechsel überlebt. In Statamic liegt Laravel darunter: Route plus Controller für den Endpunkt, Antlers oder Blade für die Bezahlseite. Dazu kommt in jedem Fall die Domain-Verifizierung, die als Teil des Deployments mitläuft.
// womit das zusammenhängt
abwicklung, strecke & leistung
// stack · schnittstelle
Der Zahlungsdienstleister, über den Apple Pay bei uns in der Regel läuft: Abwicklung, Rückerstattungen und die Händlervalidierung gegenüber Apple.
zur technik →
// stack · schnittstelle
Das Gegenstück auf der anderen Plattform — dieselbe Grundfrage: Wallet-Bestätigung als Abkürzung in einer Strecke, die auch ohne sie trägt.
zur technik →
// stack · grundlage
Progressive Enhancement als Bauweise: Die Grundfunktion trägt allein, die Erweiterung kommt dazu, wenn die Umgebung sie hergibt.
zur technik →
// stack · grundlage
Wo die Prüfdatei für die Domain-Verifizierung hingehört und warum sie nach jedem Deploy noch da sein muss.
zur technik →
// stack · grundlage
Schlüssel und Zertifikate serverseitig, TLS als Pflicht, Datensparsamkeit im Formular — und eine Erklärung, die benennt, was tatsächlich fließt.
zur technik →
// leistung · buchen
Die Komponente, in der die Bezahlstrecke entsteht — vom Produktkatalog bis zur Kasse. Hier wird gebucht.
zur leistung →
// Apple Pay in deiner Bezahlstrecke?
Projekt anfragen