Checkout-Einstellungen

Öffnen Sie Checkout in der Tapaya Platform. Die Seite zeigt Ihre Organization defaults und listet die Checkout merchants Ihrer Organisation auf. Wählen Sie einen Händler aus, um seine Einstellungsseite zu öffnen. Konfigurieren Sie einen Händler hier, bevor Sie den Hosted Checkout oder Embedded Checkout integrieren.

Was jede Integration benötigt

Arbeiten Sie die Einstellungen, die Ihre Integration verwendet, von oben nach unten durch:

Der Plattformmodus verwendet statt eines Checkout-Händlerschlüssels den Secret key der Organisation von der Seite API Keys.

Onboarding eines Händlers für Checkout

Schließen Sie das Händler-Onboarding ab und wählen Sie dabei Online-Zahlungen oder Online-Zahlungen und Zahlungen vor Ort. Beim Online-Onboarding werden die Website des Shops und die Angaben zum Online-Geschäft abgefragt. Ein Händler, der nur Checkout nutzt, benötigt keine Terminals.

Händler, die Online-Zahlungen beantragen, erscheinen automatisch unter Checkout merchants, auch solche, die noch auf die Freigabe warten. Das Anlegen eines Händlerdatensatzes oder eines Checkout-Schlüssels erteilt keine Freigabe für Online-Zahlungen. Eine Freigabe für Zahlungen vor Ort allein schaltet Checkout nicht frei.

Die Tabelle zeigt die Bereitschaft des Händlers:

Kopieren Sie das Merchant token für den Plattformmodus, oder wählen Sie Settings, um den Händler zu konfigurieren. Nur Administratoren der Organisation können Checkout-Einstellungen bearbeiten.

Checkout-Händlerschlüssel erstellen

In den Settings eines Händlers listet Merchant checkout keys die Schlüssel für das eigene Backend dieses Händlers auf. Geben Sie einen Schlüsselnamen ein und wählen Sie Create merchant key. Schlüssel beginnen in der Sandbox mit tapaya_test_ und in der Produktion mit tapaya_live_.

Kopieren Sie den geheimen Schlüssel sofort. Die Platform zeigt es nur einmal an und speichert nur einen Hash. Ein Schlüssel funktioniert nur für seinen Händler. Widerrufen Sie einen Schlüssel, um Anfragen zu stoppen, die ihn verwenden; andere Händlerschlüssel und die Schlüssel Ihrer Organisation bleiben gültig. Siehe Checkout-Authentifizierung.

Rückkehrziele konfigurieren

Hosted Checkout leitet den Kunden nach der Zahlung oder wenn er den Checkout verlässt zu Ihrem Shop zurück. Eingebettete Zahlungen verwenden keine Weiterleitungs-URLs.

Rückkehrziele gehören zu den Zugangsdaten, mit denen die Session erstellt wird:

Die beiden werden nie kombiniert, und keine greift auf die andere zurück. Eine Session im Plattformmodus kann nur zu den erlaubten Websites der Organisation zurückkehren, eine Session mit Händlerschlüssel nur zu denen des Händlers. Wenn eine Session successUrl oder cancelUrl weglässt und für ihre Zugangsdaten kein Standardwert existiert, wird die Erstellung abgelehnt.

Fügen Sie im Abschnitt für Ihre Zugangsdaten Ihren Shop zu Allowed websites hinzu und legen Sie dann Default success URL und Default cancel URL fest. Ein Shop könnte Folgendes verwenden:

• Erlaubte Website: https://shop.example.
• Erfolgs-URL: https://shop.example/checkout/return.
• Abbruch-URL: https://shop.example/checkout/cancel.

Eine erlaubte Website ist ein Origin: Schema, Host und optionaler Port, ohne Pfad, Query oder Fragment. Der Abgleich erfolgt über den exakten Origin, einschließlich des Ports. Platzhalter (Wildcards) und Hostnamen-Suffixe führen zu keiner Übereinstimmung. Verwenden Sie für bereitgestellte Shops HTTPS; HTTP wird für lokale Hosts akzeptiert.

Eine Session kann die Standardwerte beim Erstellen mit successUrl oder cancelUrl überschreiben. Überschreibungen müssen trotzdem zu einer erlaubten Website derselben Zugangsdaten passen. Eine Plattform, die Händler unter unterschiedlichen Pfaden oder Subdomains bedient, übergibt in der Regel bei jeder Session beide URLs.

Der Status Ready beschreibt die Freigabe des Händlers und die Einrichtung des Gateways. Er bestätigt nicht die Konfiguration Ihrer Rückkehr-URLs. Eingebettete Zahlungen benötigen keine Rückkehr-URLs. Gehostete Sessions benötigen Standardwerte oder ausdrücklich erlaubte URLs für die Zugangsdaten, die sie verwenden.

Ein Aufruf einer der beiden Rückkehr-URLs beweist nicht das Ergebnis der Zahlung. Rufen Sie die Session von Ihrem Server ab, bevor Sie eine Bestellung als bezahlt markieren.

Für Kunden angezeigten Namen festlegen

Der Customer-facing name wird im Checkout und in Wallets angezeigt. Lassen Sie das Feld leer, um den rechtlichen Namen des Händlers zu verwenden. Auf den Namen auf dem Kontoauszug hat diese Einstellung keinen Einfluss.

Wallets und Erscheinungsbild

Jeder Händler wählt entweder Use organization wallets and appearance oder legt eigene Werte fest. Dieser Schalter wirkt sich nicht auf die Rückkehrziele aus, die sich wie oben beschrieben nach den Zugangsdaten richten. Der Händlername und die Checkout-Schlüssel bleiben immer händlerspezifisch.

Die Organization defaults für Wallets und Erscheinungsbild gelten für jeden Händler, der sie verwendet, und Änderungen erreichen diese Händler sofort:

• Apple Pay und Google Pay. Karten sind immer aktiviert.
• Hide powered by Tapaya.
• Checkout color, eine sechsstellige Hex-Farbe wie #1380A5.
• Checkout logo, ein PNG- oder WebP-Bild mit bis zu 5 MB. Hochladen und Entfernen des Logos werden sofort gespeichert.

Wenn keine Standardwerte gespeichert wurden, sind Wallets aktiviert, und Farbe und Logo stammen aus dem Branding Ihrer Organisation.

Ein Wallet-Button hängt außerdem vom Gerät und Browser des Kunden ab. Das Aktivieren einer Wallet garantiert nicht, dass sie überall erscheint. Google Pay im Live-Modus erfordert eine konfigurierte Google Pay Merchant ID.

Hosted Checkout verwendet alle diese Einstellungen. Embedded Checkout verwendet die Wallet-Einstellungen und die wirksame Checkout-Farbe als Fokusakzent der Kartenfelder (colorFocus). Variablen, die Ihre Seite in appearance.variables übergibt, überschreiben sie. Aktivieren Sie die eingebetteten Wallet-Buttons auf Ihrer Seite wie unter Embedded Checkout beschrieben.

Prüfen Sie Branding und Zahlungsmethoden mit Checkout preview im Desktop- und im Mobil-Layout.

Shop-Domains für Apple Pay registrieren

Registrieren Sie für Apple Pay in Embedded Checkout jeden Shop-Hostnamen, auf dem die Wallet erscheint. Hosted Checkout läuft auf der Domain von Tapaya. Allowed websites für gehostete Weiterleitungen registrieren keine Domain für Apple Pay.

1. Öffnen Sie die Settings des Händlers und dann Apple Pay und Shop domains.
2. Wählen Sie Add domain und laden Sie die Verifizierungsdatei herunter.
3. Stellen Sie die Datei unverändert und ohne Erweiterung unter https://shop.example/.well-known/apple-developer-merchantid-domain-association bereit. Verwenden Sie ein gültiges HTTPS-Zertifikat und liefern Sie die Datei direkt ohne Weiterleitungen aus.
4. Geben Sie den Hostnamen ein, etwa shop.example, und wählen Sie Verify and add. Registrieren Sie www.shop.example separat, wenn Kunden auch diesen Hostnamen verwenden.
5. Warten Sie, bis die Domain Active anzeigt, und aktivieren Sie dann Apple Pay. Mit Check now diagnostizieren Sie eine fehlerhafte Domain.

Halten Sie die Verifizierungsdatei auch nach der Registrierung verfügbar. Jeder Händler benötigt eine eigene Domain-Registrierung, auch wenn Wallets und Erscheinungsbild aus den Standardwerten der Organisation stammen. Ein Händler benötigt ein konfiguriertes Payment-Gateway, bevor eine Domain registriert werden kann.

Fehlt Ihnen etwas auf dieser Seite?Wünschen Sie sich eine Funktion. Wir hängen diese Seite an, damit das Team den Kontext sieht.