Un mécanisme, de nombreux emplacements
Il n'y a ni produit ticket ni produit borne distincts : le même appel renvoie le même lien.
Offre partenaire
Un appel, un lien, partout où vous pouvez afficher un QR
Pour une plateforme de caisse, ERP, CRM ou e-commerce, l'intégration est volontairement réduite : votre système demande un lien à l'API et l'encode dans un QR code. L'endroit où ce code apparaît est un emplacement, pas une fonctionnalité distincte à développer.
La page derrière le lien est celle qu'ouvrent le terminal et le chevalet de table : rien de l'expérience client n'est à reconstruire dans votre produit.
En bref
- Ce que vous intégrez
- Une demande de lien, puis un QR que vous affichez déjà
- Emplacements
- Ticket, encart, écran de borne, page de paiement
- Ce qui suit le lien
- Caisse, établissement, service, heure, contenu du ticket
- Sous votre marque
- White-label sert la page depuis votre domaine
Mis à jour
Où vos clients le placent
Quatre emplacements, un mécanisme. Aucun ne nécessite un autre endpoint ni une autre page.
01
Imprimé sur le ticket
Receipt QR : votre caisse demande le lien à la fin de la vente et l'imprime dans le pied de ticket qu'elle contrôle déjà.
02
Sur la borne d'un tiers
Une borne en libre-service affiche le code sur l'écran après l'achat, que le client regarde déjà.
03
Dans le sac de livraison
Les Delivery Inserts portent le même lien sur une carte imprimée, sans aucune intégration avec le livreur.
04
Sur la page de paiement
Une boutique en ligne affiche le code ou le lien sur l'écran final, pour noter à la fois la commande et le paiement.
Ce que transporte le lien
Le contexte de l'achat accompagne le code
Un envoi issu d'un ticket connaît la caisse, l'adresse, le numéro de service, l'heure et le contenu du ticket. C'est ce qui distingue un rapport exploitable d'un flux d'étoiles anonymes.
La voie fiscale ne demande rien
Sur les marchés fiscalisés, le client peut scanner à la place le QR de l'administration fiscale, sans aucune intégration de votre côté.
L'attribution est automatique
L'intégration API est elle-même un identifiant employé : chaque envoi qui passe par elle est attribué à un établissement.
Questions d'intégration
Faut-il une intégration avec notre caisse ?
Non. L'application de terminal s'installe à côté de vos autres applications Android et ne touche pas au flux de paiement : elle ne nécessite donc aucune certification côté paiement. Un QR imprimé ou le QR d'un ticket fiscal ne nécessite aucune intégration. Une intégration API plus poussée existe pour les partenaires qui veulent la question dans leurs propres écrans de paiement.
Pouvons-nous l'exploiter sous notre propre marque et domaine ?
Oui. Avec White-label, la page d'avis et les e-mails système proviennent de votre domaine dans chaque canal — QR de table, ticket, terminal, borne et bot. Pour un parc de terminaux vendu sous la marque d'un acquéreur, c'est une condition du contrat plutôt qu'une option.
Card-linked recognition fonctionne-t-il réellement ?
Il est développé et en service avec un partenaire de paiement, sur des piles qui exposent le PAR ou un jeton stable au moment de la transaction. Ce n'est pas une affirmation qu'il fonctionne sur toutes les piles : sans accès au PAR, la solution de repli est un jeton stable au sein d'un même acquéreur. Le numéro de carte n'est jamais utilisé ni haché.
Combien d'applications sur le parc de terminaux ?
Une seule. La collecte d'avis est un mode de l'APK 7Stamp Scanner existant : un acquéreur certifie, versionne et maintient une seule application sur tout le parc. Une seconde application n'est ni publiée ni proposée.
Prochaine étape
Dites-nous où vous placeriez le code
Pied de ticket, écran de borne, confirmation de commande. À partir de là, nous pouvons vous dire exactement ce que représente l'intégration de votre côté.