Neu im Accept SDK: September 2026

Der September war bisher unser arbeitsreichster Monat für das Accept SDK. Wir haben acht Releases veröffentlicht, von 1.10.0 am 3. September bis 1.15.0 am 23. September. Die meisten Änderungen kamen direkt von Partnern, die das SDK produktiv einsetzen: Thekenterminals, Dual-Screen-Geräte, Geschäfte mit eigenen Kartenlesern und Plattformen, bei denen der Zahlungsschritt wie der Rest des Produkts aussehen soll.

Die Idee dahinter bleibt dieselbe. Ein Partner integriert einmal, und das Erlebnis des Händlers bleibt in seinem Produkt, während Tapaya die Komplexität der Zahlungen im Hintergrund übernimmt. Das bedeutete in diesem Monat konkret Folgendes.

Eigenes Branding auf den Zahlungsbildschirmen

1.14.0 führt Accept.setTheme() ein. Über das SDK lassen sich jetzt die Farben und Logos eines Partners an Tapaya Terminal übergeben, das sie auf den Aktivierungs-, Status- und Zahlungsbildschirmen anzeigt. Der Händler sieht vom Beginn eines Verkaufs bis zum Beleg ein einziges Produkt, ohne Übergabe an einen Bildschirm, der nach etwas anderem aussieht.

Das Theme gilt für die gesamte Sitzung. Es wird einmal gesetzt, vor oder nach initialize(), und bleibt aktiv, bis es geändert oder zurückgesetzt wird. Für Logos, die aus der Galerie des Smartphones stammen statt irgendwo gehostet zu sein, wandelt Accept.createLocalThemeImageUri() das lokale Bild in eine URI um, die die Terminal-App lesen kann.

Unterstützung für Dual-Screen-Checkout

1.10.0 unterstützt Geräte mit zwei Bildschirmen („doppelseitige“ Geräte). Accept.displays meldet, welche Bildschirme das Gerät hat, und mit der neuen Option PaymentDisplay lässt sich die Zahlungsoberfläche auf dem Bildschirm des Kunden anzeigen, während die App des Partners auf dem Bildschirm des Händlers bleibt.

Accept.payments.pay(
    amount = 1500,
    currency = "CZK",
    display = PaymentDisplay.CustomerFacing,
)

Kann das Gerät die Anforderung nicht erfüllen, etwa CustomerFacing auf einem Smartphone mit nur einem Bildschirm, greift das SDK auf den Standardbildschirm zurück. Derselbe Code funktioniert daher auf jedem unterstützten Gerät. Die neue Beispiel-App :dualscreen zeigt einen vollständigen Checkout auf zwei Bildschirmen.

Beleglinks ab dem ersten Event

1.12.0 stellt die URL des gehosteten Belegs direkt im Zahlungsablauf bereit. PaymentEvent.Created enthält jetzt receiptUrl neben dem Zahlungstoken, sodass der Link verfügbar ist, noch bevor Tapaya Terminal überhaupt geöffnet wird. Auch PayResult.Success und PayResult.Declined enthalten ihn, sodass eine abgeschlossene Zahlung alles Nötige mitbringt und kein separater status()-Aufruf mehr erforderlich ist, um einen Beleg anzuzeigen.

Der Link funktioniert ab dem Moment, in dem die Zahlung erstellt wird, und zeigt den endgültigen Beleg, sobald die Zahlung abgerechnet ist. Beide Felder können null sein und haben diesen Wert als Standard, sodass bestehende Integrationen unverändert weiter kompilieren.

Unterstützung für externe Kartenleser

1.11.0 ergänzt NfcPositionConfig.ExternalReader für Setups, bei denen der Kartenleser ein separates Gerät ist: ein Leser auf der Theke, ein Pinpad an der Seite, ein Dock, das zum Kunden zeigt. Es gibt keine Stelle am Smartphone, auf die man zeigen könnte, deshalb blendet Tapaya Terminal die Tap-Animation aus und zeigt den Betrag mit einem kurzen Hinweis darunter. Der Standardhinweis lässt sich durch eine eigene message ersetzen.

Accept.payments.setOptions(
    nfcPosition = NfcPositionConfig.ExternalReader(message = "Tap your card on the reader"),
)

Dafür ist Tapaya Terminal 1.5.2 oder neuer erforderlich. Ältere Versionen ignorieren die Einstellung und funktionieren wie bisher.

Zahlungen ohne Warten auf den Standort

Viele Partner betreiben das SDK auf Thekenterminals, und einige dieser Geräte haben einen schwachen oder nicht von Google stammenden Standortdienst. 1.14.1, 1.14.2 und 1.15.0 haben das endgültig behoben.

• pay() wartet nicht mehr auf eine neue Standortbestimmung. Es verwendet sofort den letzten bekannten Standort und aktualisiert ihn im Hintergrund, wenn er älter als eine Stunde ist. Ein Terminal auf der Theke bewegt sich zwischen zwei Zahlungen nicht, daher ist ein eine Stunde alter Standort so genau wie ein neuer.
• Wenn das SDK doch eine neue Standortbestimmung braucht, fragt es jetzt alle verfügbaren Standortquellen gleichzeitig ab und verwendet die erste Antwort. Bisher schlug ein Gerät, dessen Haupt-Standortdienst zwar intakt wirkte, aber nie antwortete, mit LocationUnavailable fehl, selbst wenn GPS und Netzwerkortung funktionierten.
• Bei einem Kaltstart verwendet das SDK zuerst den Standort, den Android bereits kennt. Nur ein Terminal, das noch nie einen Standort hatte, wartet auf einen, und zwar nie länger als 30 Sekunden.

Für Händler bedeutet das schnellere Zahlungen und deutlich weniger Standortfehler mitten in einem Verkauf.

Weitere Verbesserungen

• Klarere Fehler bei der Terminalaktivierung (1.10.0, 1.14.0). activateTerminal() gibt jetzt NoTidsAvailableForMerchant zurück, wenn einem Händler keine freie Terminal-ID mehr zur Verfügung steht, statt eines allgemeinen Unknown. Hat der Händler das Onboarding noch nicht abgeschlossen, bricht der Aufruf frühzeitig mit MerchantOnboardingIncomplete ab, sodass Sie ihn zum richtigen Schritt zurückschicken können.
• Kein Einfrieren der Oberfläche mehr beim Verbinden mit der Terminal-App (1.14.0). Aufrufe an Tapaya Terminal laufen jetzt außerhalb des Main-Threads. Bisher konnte eine langsame erste Verbindung, gestartet aus viewModelScope.launch, den Bildschirm einfrieren lassen oder einen ANR auslösen.
• Präzisere PluginUnavailable-Diagnose (1.13.0). Das SDK protokolliert jetzt, welcher Fall vorliegt: Tapaya Terminal ist nicht installiert, es ist deaktiviert, es wurde für den aktuellen Nutzer entfernt, oder im Manifest der App fehlt der <queries>-Eintrag, den Android 11+ benötigt. Das Log enthält außerdem die Version der Terminal-App und die Quelle, aus der sie installiert wurde. Außerdem haben wir ein Verbindungsleck bei fehlgeschlagenen Binds behoben, eine SecurityException, die statt PluginUnavailable beim App-Code ankam, sowie ein Warten bis zum vollen Timeout, wenn der Prozess der Terminal-App während des Verbindens abstürzte.

Aktualisieren

Jedes Release in diesem Monat ist abwärtskompatibel. Es genügt, die Abhängigkeit hochzusetzen:

dependencies {
    implementation("com.tapaya:accept:1.15.0")
}

Für Installationen auf Terminals im Einsatz empfehlen wir wegen der Standortkorrekturen besonders 1.15.0. Das vollständige Changelog finden Sie im Accept-SDK-Repository auf GitHub, die Integrationsanleitungen unter docs.tapaya.com. Die Dokumentation lässt sich über den Tapaya-MCP-Server auch mit einer IDE oder einem KI-Agenten verbinden.

Fehlt im SDK etwas, das Partner brauchen? Lassen Sie es uns wissen. Das meiste, was im September erschienen ist, begann als Gespräch mit einem Partner.