Sin impuesto Con impuesto
Achat en 1 clic RKR : Achetez en un clic avec l’adresse après paiement sur PrestaShop
Read also on our blog

Achat en 1 clic RKR : Achetez en un clic avec l’adresse après paiement sur PrestaShop

108,78 €
Première année: 108,78 € TTC
À partir de la deuxième année: 27,20 €/an TTC
  • Un an de support technique et des mises à jour à vie ; à partir de la deuxième année, le support est prolongé pour 27,20 €/an et inclut la prise en compte de vos idées d'amélioration générales du module.
  • Renouvellement automatique ; résiliable à tout moment, sans engagement.
Paiement unique: 108,78 € TTC
  • Un an de support technique et des mises à jour à vie ; ensuite, le support s'arrête (avec l'abonnement, il est prolongé pour 27,20 €/an).
  • Un seul paiement, sans prélèvement automatique.
89,90 € + TVA = 108,78 €

Permettez à vos clients d'acheter directement depuis la page produit, leur panier ou la fiche produit dans une fenêtre modale, et de fournir leur adresse de livraison après validation de la commande via un lien temporaire ou depuis leur compte. Une fois l'adresse reçue, les frais de port sont recalculés automatiquement. Ce module inclut des rappels, 23 thèmes et des statistiques. Testé sur les versions 1.7.8.11 , 8.2.8 , 9.0.0 et 9.2.1. Un module Rekire .

Compatible avec PrestaShop 1.7.8 à 9.2.

Essayez la démo

Front officeBack office

Contenu expert

Vérifié par nos experts

Written by

Reviewed by

See all our experts

Contenu rédigé et vérifié par des professionnels qualifiés. Les informations sont fournies à titre indicatif.

Achetez en 1 clic

Chaque champ du formulaire de paiement représente une vente manquée.

Le client a déjà décidé d'acheter et se retrouve face à un long formulaire lui demandant une adresse qu'il n'a pas encore besoin de fournir. L'achat en un clic de RKR lui permet d'acheter directement depuis la page produit, le panier ou la fiche produit dans une fenêtre modale, l'adresse de livraison étant disponible après le paiement s'il le souhaite.

23 sujets
avec aperçu en direct, le bouton et la fenêtre modale s'intègrent parfaitement à votre boutique.
6 graphiques
Statistiques du module : séries chronologiques, revenus, passerelles, entonnoir de conversion, états et carte thermique
PrestaShop 1.7.8 → 9.2
Testé de bout en bout sur les 1.7.8.11 , 8.2.8 , 9.0.0 et 9.2.1 , avec PHP 7.4 à 8.5.

/ Achats auprès des endroits où ils recherchent déjà

Le bouton « Acheter en 1 clic » apparaît sur la page produit, dans le panier et dans les annonces. Il ouvre une fenêtre modale personnalisée, affichant votre nom, votre adresse e-mail, votre numéro d'identification (carte d'identité ou numéro d'étudiant), votre numéro de téléphone et une note facultative. Vous pouvez y saisir directement votre adresse de livraison, choisir parmi vos adresses enregistrées ou la renseigner après la validation de votre commande.

Paiement , aucune étape supplémentaire

Virement bancaire, chèque et paiement à la livraison
La commande est créée instantanément, avec le statut « En attente d'adresse en un clic ». Il n'y a pas besoin d'attendre l'enregistrement de la vente.
Les autres podiums
Le client accède directement à l'étape de paiement de la page de paiement native de PrestaShop, avec la passerelle de paiement choisie déjà sélectionnée.

L' adresse arrive plus tard et les frais de port sont recalculés correctement.

Si le client laisse l'adresse pour plus tard, il peut la compléter via un portail en utilisant un lien envoyé par e-mail (délai d'expiration : 30 jours par défaut, modifiable), ou en se connectant avec sa référence de commande et son adresse e-mail. S'il possède un compte, il peut également le faire depuis « Mes commandes en 1-Click » dans son compte.

Lorsque l'adresse est reçue, le module recalcule les frais de port en utilisant les règles natives de PrestaShop (zone, fourchettes de prix ou de poids, frais de manutention, livraison gratuite), met à jour les totaux, le transporteur et la facture, et la commande passe au statut qui correspond à sa passerelle de paiement.

Un compte enregistré n'est jamais utilisé sans connexion : si l'adresse e-mail appartient déjà à un client, le module lui demande de se connecter avant d'effectuer un achat.

Transports et rappels

Transporteur express propriétaire
Livraison rapide au prix que vous fixez, et livraison gratuite pour les commandes dépassant le montant que vous choisissez. Vous pouvez également utiliser les transporteurs de votre boutique.
Rappels avec une limite
Des courriels automatisés sont envoyés à ceux qui n'ont pas fourni leur adresse, avec un nombre maximal de notifications, et une alarme dans le back-office tous les N jours pour renvoyer, reporter ou ouvrir la commande.
Courriels en espagnol et en anglais
Adresse en attente, rappel et adresse reçue.

C'est vous qui décidez où oui et où non.

Vous pouvez limiter le bouton par catégorie ou exclure certains produits. Pour un catalogue où les ventes en un clic ne sont pas pertinentes, vous pouvez le désactiver à cet endroit et le laisser activé ailleurs.

Un panneau complet, sans quitter le back-office

11 onglets de paramètres
Généralités, mode modal, méthodes de paiement, adresse et transporteur, e-mails, commandes en 1 clic, statistiques, import/export, thèmes, guide et démo.
Statistiques
Des indicateurs et 6 graphiques permettent de visualiser le volume des ventes réalisées en un clic et par quelle passerelle.
Importation et exportation
Configuration au format JSON ou CSV et commandes au format CSV, pour transférer les paramètres d'un magasin à un autre.
données intégrées du guide et de la démonstration
Le guide se trouve dans le module lui-même, et les exemples de données peuvent être chargés et supprimés sans laisser de trace.

La sécurité et ce qui nous inquiète

Les liens du portail ne sont pas enregistrés en clair et expirent ; une protection contre le double-clic est intégrée, et les formulaires incluent des jetons anti-CSRF, des limites de requêtes et des champs anti-bots. Il s'agit d'une plateforme multi-boutiques disponible en espagnol et en anglais.

Si RKR Select City est installé, son sélecteur de ville avec recherche et validation téléphonique internationale est automatiquement activé dans la fenêtre modale et le portail. Son utilisation est facultative.

Pour les rappels, exécutez l'URL cron affichée dans l'onglet Général toutes les heures, ou utilisez le module natif « Gestionnaire de tâches Cron ». Sans cron, les tâches s'exécutent une fois par jour à l'ouverture du back-office. AFL-3.0.

Compatible avec PrestaShop 1.7.8 à 9.2

Développé et maintenu par REKIRE

  • Référence
    rkroneclickinstantbuy

05/11/2026
v1.1.1

Ajouté

  • Première version publiée avec la fusion des achats dans une commande en attente ( introduite dans la 1.1.0 ) : un client qui effectue un nouvel achat alors que sa commande en un clic est toujours en attente de confirmation d’adresse de livraison verra les nouveaux produits ajoutés à cette commande (un seul envoi, une seule adresse, un seul paiement) au lieu de passer une seconde commande. Paramètres dans Paiement et fenêtre modale → Fusion des commandes en attente.

Fixé

  • Le document « Script terminé » s’affichait par erreur sur chaque page : il était placé à la fin du modèle de document « actifs du front office ».
  • upgrade/ upgrade-1.1.0.php a été supprimé : les fonctions de mise à niveau étant globales, une boutique où un autre module avait déjà chargé un fichier portant le même nom de fonction a signalé l'impossibilité de mettre à niveau le module, qui a donc ignoré l'opération. Le module met à jour son schéma automatiquement ( RkrOcibDb::ensureSchema() , exécuté une fois par version) et les nouveaux paramètres ont des valeurs par défaut à l'exécution ; aucun script de mise à niveau n'est donc nécessaire.
  • La fusion des achats n'a jamais eu lieu : le verrou de ligne a été lu avec Db::getRow() , qui ajoute son propre LIMIT 1 après FOR UPDATE (erreur de syntaxe SQL), de sorte que chaque achat a été ramené à une nouvelle commande en attente.
  • Les unités fusionnées ont quitté stock_available.quantity sans atteindre reserved_quantity (le stock physique a cessé de s'accumuler) et les lignes de taxe d'une ligne de commande étendue n'ont pas été mises à jour : la fusion se termine désormais par les deux mêmes appels que PaymentModule::validateOrder() effectue ( updateOrderDetailTax() et la synchronisation du stock réservé/physique).
  • Les commandes avec règles de panier (remises, bons d'achat, livraison gratuite) ne sont plus fusionnées : leurs valeurs de remise enregistrées ne correspondraient pas aux totaux recalculés à partir du panier complet.
  • Les règles de panier automatiques (bon de bienvenue, remise sur seuil) appliquées par Cart::updateQty() ont été intégrées au panier de la commande fusionnée : le total de la commande a diminué d'une remise qui n'a jamais été enregistrée ni utilisée. Ces règles ont été supprimées du panier et aucune remise n'y a été appliquée.
  • Les achats comportant des produits cachés ajoutés par d'autres modules (frais de paiement, assurance expédition, articles cadeaux) et les commandes dont le panier a été divisé en plusieurs commandes ne sont plus fusionnés : les articles cachés seraient facturés deux fois et les totaux incluraient les produits des autres commandes. Si le panier d'une autre commande est modifié par un autre module pendant la fusion, il est rétabli et l'achat fait l'objet d'une commande distincte.
  • La fusion ne s'effectue plus au sein d'une seule transaction SQL : les hooks de stock et de panier des autres modules attendaient jusqu'à 50 secondes sur les lignes verrouillées (et certains validaient même partiellement). Un verrou nommé par commande ( GET_LOCK ) empêche la fusion de deux achats dans la même commande. Un échec survenant lors de la modification de la commande est consigné comme merge_partial et renvoyé par une erreur, sans jamais créer une seconde commande pour les mêmes produits.

Sécurité

  • Portée « même adresse e-mail » : la saisie de l’adresse e-mail d’une commande en attente d’un autre utilisateur ne donne plus accès au portail de cette commande (la redirection a enregistré le cookie de recherche correspondant), ni à sa référence ou à son montant. Un visiteur qui n’est pas le titulaire de la commande est informé que le lien lui a été envoyé par e-mail, et l’adresse e-mail de la commande en attente est toujours redirigée vers le propriétaire de l’adresse e-mail.
  • L'adresse e-mail de portée est celle du compte résolu, jamais celle saisie dans la fenêtre modale.

05/11/2026
v1.1.0

Ajouté

  • Fusion des achats avec une commande en attente : lorsqu’un client effectue un nouvel achat alors qu’une de ses commandes en un clic est toujours en attente d’adresse de livraison, les nouveaux produits sont ajoutés à cette commande (détails de la commande, mouvements de stock, panier et totaux) au lieu de créer une seconde commande. Le client est redirigé vers le portail de confirmation de commande de sa commande initiale et peut recevoir à nouveau l’e-mail de confirmation d’adresse de livraison avec le total mis à jour.
  • Nouveaux paramètres dans Paiement et Modal → Fusion des commandes en attente : étendue (désactivée / même compte client / même adresse e-mail), fenêtre de fusion en heures, nombre maximal de fusions par commande, exigence de même méthode de paiement, montant maximal fusionné et renvoi de l'e-mail.
  • Colonne merge_count sur les enregistrements du module, affichée dans l'onglet Commandes en un clic, sur la fiche de commande du back-office et dans le panneau du compte client ; événements de journalisation order_merged / submit_merged ; revenus fusionnés ajoutés aux statistiques du jour de commande d'origine.
  • Section du guide « Fusionner les achats dans une commande en attente » et traductions espagnoles de chaque nouvelle chaîne de caractères.
  • upgrade/ upgrade-1.1.0.php plus une auto-réparation de schéma sur place ( RkrOcibDb::ensureSchema() ) pour les boutiques mises à niveau en remplaçant le dossier du module.

Fixé

  • product_list des produits du module stockait le stock disponible au lieu de la quantité achetée : les lignes Cart::getProducts() exposent la quantité commandée via cart_quantity ( quantity est IFNULL(stock.quantity, 0) dans la requête principale). Le récapitulatif généré pour chaque achat, et pour chaque fusion, est désormais correct.
  • La fusion n'a jamais eu lieu : le verrou de ligne a été lu avec Db::getRow() , qui ajoute son propre LIMIT 1 après FOR UPDATE (erreur de syntaxe SQL), de sorte que chaque achat a été ramené à une nouvelle commande en attente.
  • Les unités fusionnées ont quitté stock_available.quantity sans atteindre reserved_quantity (le stock physique a cessé de s'accumuler) et les lignes de taxe d'une ligne de commande étendue n'ont pas été mises à jour : la fusion se termine désormais par les deux mêmes appels que PaymentModule::validateOrder() effectue ( updateOrderDetailTax() et la synchronisation du stock réservé/physique).
  • Les commandes avec règles de panier (remises, bons d'achat, livraison gratuite) ne sont plus fusionnées : leurs valeurs de remise enregistrées ne correspondraient pas aux totaux recalculés à partir du panier complet.
  • Le modèle des éléments du front office se terminait par un texte isolé : « Script terminé. »

Sécurité

  • Portée « même adresse e-mail » : la saisie de l’adresse e-mail d’une commande en attente d’un autre utilisateur ne donne plus accès au portail de cette commande (la redirection a enregistré le cookie de recherche correspondant), ni à sa référence ou à son montant. Un visiteur qui n’est pas le titulaire de la commande est informé que le lien lui a été envoyé par e-mail, et l’adresse e-mail de la commande en attente est toujours redirigée vers le propriétaire de l’adresse e-mail.
  • L'adresse e-mail de portée est celle du compte résolu, jamais celle saisie dans la fenêtre modale.
  • Les fusions s'exécutent dans une seule transaction SQL avec la ligne d'enregistrement verrouillée ( SELECT ... FOR UPDATE ) et revérifient l'indicateur en attente, de sorte que deux soumissions simultanées ne peuvent jamais fusionner deux fois.

Compatibilité

  • La fusion est implémentée uniquement avec les classes de modèle d'objet héritées ( Cart::updateQty , OrderDetail::createList , StockAvailable::updateQuantity ) : comportement identique sur PrestaShop 1.7.8 → 9.2 et aucune dépendance au conteneur Symfony, qui n'est pas accessible depuis le front office sur PrestaShop 9.x.

24/10/2026
v1.0.3

Fixé

  • Statistiques : les titres contenant « & » n'affichent plus « & ».

4 autres produits de la même catégorie

Questions and answers

  • ¿Dónde aparece el botón y qué datos pide?

    Equipo de Rekire

    0

    • El botón «Comprar en 1 clic» aparece en la ficha de producto, en el carrito y en los listados, y abre un modal con el estilo de tu tema que pide nombre, email, DNI/NIE, teléfono y una nota opcional. La dirección se puede escribir ahí, elegir entre las guardadas o dejarla para después del pago. Puedes restringir el botón por categorías o excluir productos.

      Equipo de Rekire The shop

  • Si el cliente da la dirección después, ¿cómo se calcula el envío?

    Equipo de Rekire

    0

    • El cliente completa la dirección desde un portal con un enlace que le llega por email y que caduca (30 días por defecto), entrando con la referencia del pedido y su email, o desde «Mis pedidos de 1 clic» en Mi cuenta. Al llegar, el módulo recalcula el envío con las reglas nativas de PrestaShop (zona, rangos de precio o peso, manipulación, envío gratis), actualiza totales, transportista y factura, y el pedido pasa al estado que le corresponde según su pasarela.

      Equipo de Rekire The shop

  • ¿Funciona con todas mis formas de pago?

    Equipo de Rekire

    0

    • Con transferencia, cheque y contra reembolso el pedido se crea al momento en el estado «Pendiente de dirección ONE CLICK». Con las demás pasarelas, el cliente va directo al paso de pago del checkout nativo de PrestaShop con la pasarela elegida ya marcada.

      Equipo de Rekire The shop

  • ¿Qué pasa si el email ya pertenece a un cliente registrado?

    Equipo de Rekire

    0

    • Una cuenta registrada nunca se usa sin iniciar sesión: si el email ya es de un cliente, el módulo le pide que entre antes de comprar. Además, los enlaces del portal no se guardan en claro y caducan, y los formularios llevan token anti-CSRF, límite de peticiones y campo trampa contra bots.

      Equipo de Rekire The shop

  • ¿Cómo recuerdo al cliente que me falta su dirección?

    Equipo de Rekire

    0

    • El módulo envía emails automáticos de recordatorio a quien no ha dado la dirección, con un máximo de avisos, y te pone una alarma en el back-office cada N días para reenviar, posponer o abrir el pedido. Para los recordatorios, llama cada hora a la URL del cron de la pestaña General o usa el módulo nativo «Cron tasks manager»; sin cron se ejecutan una vez al día al abrir el back-office.

      Equipo de Rekire The shop

  • ¿En qué versiones se ha probado?

    Equipo de Rekire

    0

    • Se ha probado de extremo a extremo en PrestaShop 1.7.8.11, 8.2.8, 9.0.0 y 9.2.1, con PHP 7.4 a 8.5. Es multitienda y viene en español e inglés. Si tienes RKR Select City, su selector de ciudad y la validación internacional de teléfono se activan solos dentro del modal y del portal; es opcional.

      Equipo de Rekire The shop

Consentement aux cookies
Retour en haut