Warum dies das richtige Verhalten ist
Die Betrugs-Warteschlange existiert, weil Online-Checkouts Card-Not-Present laufen. Shopifys Risk-API markiert Muster, die mit der Verwendung gestohlener Karten korrelieren — nicht übereinstimmende Rechnungsadressen, Anonymisierungs-Proxies, Geschwindigkeit von einer IP. Keines dieser Signale gilt am POS: Die Karte wurde im Geschäft eingesteckt, getippt oder gewischt, der Aussteller hat sie auf der Stelle authentifiziert, und die Rückbuchungs-Haftung wechselt bei einem Chip-und-PIN-Verkauf zum Aussteller. Die Bestellung zurückzuhalten würde bedeuten, dass ein Kunde an der Theke auf eine E-Mail wartet, die der Händler ebenfalls zurückhält. Sofortige Lizenzschlüssel-Zuweisung ist hier, was Händler wollen.
Was das in der Praxis bedeutet
Drei konkrete Konsequenzen ergeben sich aus dem POS-Bypass:
- Lizenzschlüssel werden sofort zugewiesen. Der Käufer geht mit einem funktionierenden Code, nicht mit einem ausstehenden.
- Die Download-E-Mail feuert am ORDERS_PAID-Webhook. Wenn die Bestellung gegen ein Kunden-Profil im POS eingetippt wurde, landet die E-Mail innerhalb von Sekunden nach dem Beleg-Druck.
- Die Bestellung erscheint nie in der Betrugs-Warteschlange. Keine
FraudCheckQueue-Zeile, kein Shopify-Risk-API-Aufruf, kein Risiko-Score irgendwo im Alva-Admin.
Alva-Admin → Bestelldetailseite für eine POS-Bestellung. Zeigen Sie den Bestell-Header mit dem Shopify-„Point of Sale“-Channel-Pill und einen kleinen „Betrugsprüfung übersprungen — POS-Bestellung“-Indikator nahe dort, wo normalerweise der Risiko-Score erscheinen würde. Alternative: die leere Betrugs-Warteschlange mit einem Footer-Hinweis, dass POS-Bestellungen ausgeschlossen sind.
Wo dies im Code durchgesetzt wird
Der Bypass lebt in app/models/webhooks.server.neworder.ts bei Zeile 79. Der Handler liest die Kunden-ID aus der Payload und kürzt ab, wenn keine vorhanden ist, protokolliert „Order <number> has no customer (POS/guest/draft order), skipping digital delivery“ und kehrt zurück, bevor irgendein Code-Pfad, der die Shopify-Risk-API oder die FraudCheckQueue-Tabelle berührt, läuft. Es gibt keinen Schalter, kein Override pro Shop, kein Per-Bestellung-Schlupfloch.
Zu beachtende Nebeneffekte
Das Überspringen der Risk-API bedeutet, POS-Bestellungen tragen nirgendwo in Alva einen Risiko-Score. Wenn ein bestimmter In-Store-Verkauf später manuell überprüft werden muss, öffnen Sie die Bestellung im Alva-Admin und klicken Sie auf Zugriff deaktivieren — Download-Links funktionieren nicht mehr, und etwaige zugewiesene Lizenzschlüssel kehren in den Pool zurück. Die vollständige Anleitung ist unten verlinkt.
Siehe auch
Häufig gestellte Fragen
Nein. Der POS-Zweig ist bedingungslos — Alva kürzt ab, bevor es die Shopify-Risk-API für irgendeine Bestellung ohne Kunden-Datensatz erreicht. Verwenden Sie für die manuelle Prüfung Zugriff deaktivieren auf der Alva-Bestelldetailseite.
Öffnen Sie die Bestellung im Alva-Admin und klicken Sie auf Zugriff deaktivieren. Download-Links funktionieren sofort nicht mehr, und etwaige zugewiesene Lizenzschlüssel kehren in den Pool zurück.
Es gilt für jede bezahlte Bestellung ohne Kunden-Datensatz auf der Webhook-Payload — POS-Verkäufe, ohne angehängten Kunden konvertierte Entwurfsbestellungen und Gast-Checkouts. Alle drei überspringen Betrugsprüfungen aus demselben Grund.
War das hilfreich?
Zuletzt aktualisiert 2026-05-06