Revue de l’entreprise et du catalogue
Le marchand complète le KYB et identifie les sites, apps, produits ou services vendus. Les activités interdites ou restreintes sont examinées avant le live, pas après l’intégration du checkout.
Paiements e-commerce
Laissez chaque client payer à sa façon. Reliez chaque paiement à sa commande.
Utilisez le checkout hébergé, les liens de paiement ou l’API pour accepter les méthodes activées pour chaque opération—notamment stablecoins, cartes et mobile money lorsque disponibles—tout en préservant références commande, états signés et rapprochement finance.
- Checkout hébergé ou API
- Références commande stables
- Aucun plugin non vérifié
Adéquation et onboarding
La surface de paiement doit correspondre à la boutique, au catalogue et à la livraison.
ZyndPay accompagne les entreprises approuvées qui encaissent et règlent en ligne. La revue d’onboarding couvre l’entité juridique, les bénéficiaires effectifs, les produits, les canaux de vente, la livraison, les remboursements, les pays et les flux attendus avant l’activation des méthodes live.
Contexte client et marché
Les méthodes disponibles dépendent du client, de la devise, du pays et de la configuration activée du compte. Le mobile money est un rail utile là où il est habituel, pas l’identité mondiale de ZyndPay ni une promesse universelle.
Responsabilité livraison et remboursement
Le marchand reste responsable de la qualité, la livraison, la politique d’annulation, le service client et les décisions légales de remboursement. ZyndPay enregistre et exécute les actions de paiement prises en charge dans le service convenu.
Vérité des artefacts d’intégration
Checkout hébergé, liens de paiement et API sont les parcours publics. Cette page n’annonce aucun plugin WooCommerce, WordPress ou panier sans artefact public maintenu.
De la commande au cash
Reliez panier, paiement et finance avec une référence unique.
Le marchand crée un paiement pour une vraie commande, oriente l’acheteur vers un parcours activé, attend l’état faisant autorité, livre selon sa politique et rapproche chaque exception sur la même référence.
- 01
Créer une référence commande immuable
Générez une référence marchande unique et un montant dans les bonnes unités mineures. Conservez prix, taxes, livraison et stock dans le système commerce qui détient la commande.
- 02
Ouvrir le checkout ou partager un lien
Redirigez vers le checkout hébergé, créez un lien de paiement ou utilisez le flux API pris en charge. L’acheteur voit les méthodes activées pour ce compte et ce contexte.
- 03
Attendre l’état serveur confirmé
Utilisez événements asynchrones signés et contrôles authentifiés. Retour navigateur, capture et message client ne prouvent pas le règlement et ne doivent pas déclencher seuls la livraison.
- 04
Livrer et communiquer clairement
Faites avancer la commande selon votre propre politique de paiement confirmé. Rendez les états en attente, échoué, expiré, remboursé et contesté compréhensibles par le support.
- 05
Rapprocher et régler
Reliez identifiants ZyndPay, commandes, événements, remboursements et règlements. Tarification, délai de règlement et retraits disponibles restent propres au compte.
Opérations commerce
La conversion compte. La traçabilité la rend exploitable.
Checkout hébergé responsive
Utilisez une surface ZyndPay adaptée au mobile et au desktop tandis que votre boutique conserve catalogue, commande et livraison.
Liens de paiement
Créez un parcours partageable pour facture, vente à distance ou checkout assisté, avec une référence marchande reliée au même modèle de rapprochement.
API de paiement
Créez et observez les flux pris en charge depuis votre back-end pour relier plus étroitement panier, abonnement, gestion des commandes ou workflows internes.
Acceptation stablecoin
Acceptez les paires actif-réseau USDT ou USDC activées. La paire et l’adresse exactes affichées doivent être utilisées ; finalité blockchain et risque de l’actif restent pertinents.
Rails de paiement locaux
Présentez les options carte ou mobile money activées là où elles existent, sans coder un prestataire en dur ni supposer les mêmes méthodes dans chaque marché.
Remboursements et rapprochement
Suivez remboursements et exceptions pris en charge séparément de l’encaissement original, puis comparez commande, paiement et règlement avec des identifiants stables.
Vérité opérationnelle
Un identifiant de paiement doit expliquer la commande de la tentative au règlement.
L’expérience acheteur, votre système commande et les registres finance avancent à des vitesses différentes. Une bonne intégration préserve leur lien sans réduire en attente, confirmé, remboursé et réglé à un vague indicateur « payé ».
- Preuve acheteur
- La page de retour explique la suite au client. Elle ne remplace pas l’état serveur signé ou authentifié utilisé par le marchand.
- Preuve finance
- État du paiement, état du remboursement, règlement et retrait sont liés mais distincts. Rapprochez-les au lieu de dériver chaque réponse de la boutique.
- Preuve commerciale
- Les frais et conditions applicables sont affichés pour le compte et l’opération avant le live. Cette page ne contient volontairement aucune grille universelle.
Choisir un parcours
Lancez vite, puis intégrez à la profondeur nécessaire.
Checkout hébergé
Orientez les acheteurs vers une surface responsive et consommez le résultat confirmé dans votre système de commande.
Découvrir le checkoutLiens de paiement
Encaissez une facture ou une vente assistée sans construire immédiatement un checkout personnalisé complet.
Découvrir les liens de paiementAPI de paiement
Reliez création, états et événements à un panier personnalisé, un système de commandes ou un back-end commerce.
Découvrir l’API de paiementFAQ
Questions paiement e-commerce
Quels moyens de paiement une boutique peut-elle accepter ?
Un compte approuvé peut proposer les méthodes stablecoin, carte et mobile money activées. Le checkout live ou la réponse API fait autorité car la disponibilité varie selon compte, marché, devise, contexte client et état du rail.
ZyndPay propose-t-il un plugin WooCommerce ou WordPress ?
ZyndPay ne promeut actuellement aucun plugin commerce public maintenu. Les parcours vérifiés sont le checkout hébergé, les liens de paiement et l’API. Un plugin ne doit être nommé qu’après vérification de son artefact public et de sa maintenance.
Puis-je livrer quand l’acheteur revient sur mon site ?
N’utilisez pas le retour comme seule preuve. Confirmez l’état serveur faisant autorité et consommez les événements signés de façon idempotente ; l’acheteur peut fermer la page tôt ou le rail rester en attente.
ZyndPay peut-il régler chaque paiement en stablecoins ?
Actifs de règlement, délais et parcours de retrait dépendent du compte approuvé, du rail d’origine, des paires actif-réseau activées et des conditions. Ils sont confirmés à l’onboarding et dans les surfaces du compte, pas garantis ici.
Comment fonctionnent les remboursements ?
Les demandes prises en charge restent des opérations distinctes liées au paiement original. Éligibilité, destination, finalité et délai dépendent de la méthode d’origine ; un transfert blockchain ne s’annule pas toujours comme un paiement carte.
ZyndPay publie-t-il les frais de transaction e-commerce ?
Aucun frais universel n’est publié. La tarification applicable est propre au compte et communiquée dans le dashboard, le checkout, les réponses API ou les conditions marchandes avant le live.
Onboarding marchand
Connectons les paiements à votre boutique.
Partagez l’entité juridique, les domaines ou apps, les produits vendus, les marchés, devises, moyens attendus, modèle de remboursement et responsable technique. L’équipe qualifie alors le compte et le parcours sans deviner la disponibilité.