01Tous les moyens de paiement sur une page
Le checkout hébergé réunit cartes, Apple Pay, Google Pay et USDC côte à côte. La commande 9F21-0716 est à gauche — trois lignes, €0.50 de frais de traitement, €49.00 à régler — et le choix du moyen de paiement à droite. Le client choisit ; la page s'adapte ; le marchand n'a intégré qu'une fois.
- Boutons carte, USDC et wallets sur le même écran
- La commande complète — articles, frais, total — à côté du formulaire de paiement
- Une seule action Payer €49.00, quel que soit le moyen de paiement
02Le mobile depuis la même URL
La même URL de checkout se réorganise en mise en page mobile : la commande se replie en barre récapitulative, les boutons de paiement restent en place, le formulaire de carte garde ses libellés. Ce qui est livré sur desktop l'est sur mobile — et si vous voulez que le paiement se fasse dans votre propre app plutôt que dans un navigateur, les SDK iOS et Android présentent le même checkout en natif, sur la même commande.
03Des reçus qui s'expliquent d'eux-mêmes
Un paiement en USDC se termine par un reçu que le comptable du marchand peut lire. Moyen : 52.95 USDC sur Base →︎ règlement en EUR, au taux imprimé sur le reçu, 1 EUR = 1.0807 USDC. Référence 9F21-0716, envoyée par e-mail au client et téléchargeable immédiatement. Le client a payé en crypto ; la comptabilité indique €49.00.
04Un back-office de liens, pas seulement des liens
Les liens de paiement ont un vrai poste de pilotage : 8 liens pour Arc Studio SRL, payés, actifs ou expirés, avec montant, nombre de paiements et statut sur chaque ligne. Les cartes du haut font le décompte — 4 liens actifs, €2,304.50 encaissés ce mois-ci sur 18 paiements par lien, €49.00 payés aujourd'hui. Créer, rechercher, exporter, terminé.
- Chaque lien avec son URL, son montant et son statut
- Encaissé ce mois-ci et payé aujourd'hui en haut de page
- Créez un lien dans la vue même où vous les suivez
05Remboursements rattachés à la commande
Un remboursement porte sur la commande, pas sur un moyen de paiement. Le panneau s'ouvre sur 9F21-0716 avec le montant prérempli à €49.00 en totalité, un motif obligatoire et une note facultative qui figure dans les exports et sur le reçu du client. Les fonds repartent automatiquement par le rail de paiement d'origine — remboursement sur la carte pour les cartes, règlement EUR pour les commandes USDC — généralement sous 1 à 3 jours ouvrés.
- Total ou partiel — tout montant jusqu'à celui du débit initial
- Motif obligatoire, note reportée sur le reçu
- Le circuit d'origine annulé automatiquement, quel que soit le rail
06Votre checkout, à votre image
Le branding se règle dans une page de paramètres, pas dans une mission de services : importez un logo, définissez les couleurs d'accent, de texte et de fond, choisissez la police et le style des angles. L'aperçu en direct affiche votre vrai checkout — desktop ou mobile — avant d'enregistrer, et l'accent pilote le focus du bouton de paiement, les coches de statut et l'onglet actif. Déployez-le sur l'hôte de checkout fourni avec votre sandbox, ou sur votre propre domaine.
07Des moyens de paiement qu'on active, pas qu'on développe
Les moyens de paiement sont des interrupteurs, avec des prestataires derrière : cartes avec 3-D Secure, Apple Pay et Google Pay en boutons wallet, USDC sur Ethereum, Base et Solana, virement SEPA par référence vIBAN. À côté, le panneau de règlement pose les choses clairement : les clients voient la conversion avant de confirmer ; vous êtes toujours réglé en EUR.
- Un interrupteur par moyen de paiement, avec le prestataire nommé sur la ligne
- Règlement USDC : conversion automatique, versement quotidien à 23:00
- Routage des cartes avec politique 3-D Secure visible
08Intégration drop-in
Créez une commande, redirigez vers la page hébergée, recevez le résultat. Gateway porte l'interface de paiement, la logique des moyens de paiement et les reçus. Aucun frontend de checkout à développer, corriger ou maintenir à jour pour votre équipe quand les moyens de paiement évoluent.
09La commande est l'unité de référence
Tout repose sur la commande, pas sur le moyen de paiement. La commande 9F21-0716 porte ses lignes — un sprint d'identité de marque à €38.50, €6.00 de licence typographique, €4.00 de livraison express — €0.50 de frais de traitement et un seul total. Quel que soit le moyen de paiement, cette référence sert à interroger, rapprocher et rembourser.
10Une config qui ne surprend jamais une session
Les changements de moyens de paiement et de branding s'appliquent aux nouvelles sessions de checkout — c'est indiqué sur l'écran où vous les enregistrez. Un client en plein paiement ne voit jamais la page changer sous ses doigts.
11Les cartes, faites correctement
Le parcours carte, c'est la partie ingrate, prise en charge : validation en ligne, 3-D Secure avec authentification forte du client intégrée au flux selon une politique de routage lisible, et cartes de test par sandbox pour vos phases d'intégration. Accepter la crypto ne dégrade jamais le parcours carte.
12Apple Pay et Google Pay
Les wallets sont des boutons, pas des projets. Apple Pay et Google Pay s'affichent en feuilles de paiement d'un geste sur la même page et paient avec des tokens d'appareil — le vrai numéro de carte n'atteint jamais la page — via la même commande et le même reçu. Les activer se fait par un interrupteur sur l'écran des moyens de paiement.
13USDC réglé en EUR
La crypto est tarifée à un taux affiché au checkout et réglée en euros. Le marchand ne se retrouve jamais avec une position en tokens par accident ; la comptabilité reste dans une seule devise.
14USDC sur trois réseaux
Le moyen de paiement USDC couvre Ethereum, Base et Solana derrière un seul interrupteur. Le client paie sur le réseau où se trouve son wallet ; côté marchand, rien ne change.
15Virement bancaire par vIBAN
Le paiement par virement porte une référence vIBAN : un paiement SEPA entrant identifie donc sa commande par construction. Activez-le pour les clients qui veulent une facture à régler depuis leur banque, et le rapprochement reste automatique.
16Des moyens locaux là où ils comptent
Au-delà des cartes et des wallets, le checkout propose les paiements de compte à compte et les moyens locaux qu'un acheteur européen s'attend à trouver, présentés selon le pays du client plutôt qu'entassés dans une longue liste.
17Buy now, pay later
Le BNPL figure sur la même ligne que les autres moyens de paiement — le client fractionne son paiement, le marchand est payé en une fois, et la référence de commande ne change pas. Un interrupteur, le même reçu, le même rapprochement.
18Des moyens de paiement qui lisent le client
La page classe les moyens de paiement selon ce que le client est susceptible d'utiliser — pays, langue, appareil, et s'il a déjà payé chez vous — pour que l'option pertinente soit la première, pas la quatrième.
19Affiché dans leur devise, réglé dans la vôtre
Affichez le montant dans la devise du client avec la conversion indiquée avant confirmation, et réglez en EUR quoi qu'il arrive. Le client voit un montant familier ; votre ledger n'en garde qu'un.
20Un checkout dans leur langue
La page hébergée localise ses libellés, ses erreurs et ses reçus. Personne n'abandonne un paiement parce que le bouton n'était pas dans sa langue.
21Cartes enregistrées et paiement en un clic
Un client qui revient paie avec une carte enregistrée en un geste. La carte est conservée dans notre coffre et référencée par token : vos systèmes stockent une référence, jamais un PAN — et le deuxième achat est plus court que le premier.
22Abonnements et facturation récurrente
Les prélèvements récurrents suivent un calendrier que vous définissez — montant, intervalle, début et fin — sur une carte tokenisée. Chaque cycle produit sa propre commande et son propre reçu : un abonnement se rapproche ligne à ligne, comme tout le reste.
23Des relances qui récupèrent du revenu
Un refus temporaire sur un prélèvement récurrent est relancé selon un calendrier plutôt que passé en perte, et le client n'en est informé que lorsque c'est utile. Les renouvellements échoués cessent d'être du churn silencieux.
24Tokens réseau et mises à jour de cartes
Les cartes enregistrées sont conservées sous forme de tokens réseau et suivent le porteur à travers les réémissions et les expirations. L'abonnement qui cassait au remplacement d'une carte continue d'être prélevé.
25Une API et un espace développeurs
Les commandes se créent par API avec des clés d'idempotence — une requête rejouée renvoie le résultat d'origine, jamais un second débit — et la section développeurs regroupe les clés et la documentation. Le checkout est hébergé ; l'intégration tient en une poignée d'endpoints, documentés là où se trouvent les paramètres.
26Webhooks sur le cycle de vie de la commande
Votre backend est informé des paiements à l'instant où ils se produisent : des événements webhook signés sur le cycle de vie de la commande — payée, échouée, remboursée — avec vérification de la signature de votre côté et protection contre le rejeu du nôtre.
27SDK mobiles pour iOS et Android
Les apps natives présentent le même checkout dans l'app plutôt que d'envoyer l'utilisateur dans un navigateur. Le SDK embarque la logique des moyens de paiement, les feuilles de wallets et 3-D Secure ; la commande et le reçu sont ceux que votre backend connaît déjà.
Les plugins de panier connectent une boutique existante à Gateway sans développeur — installez, collez les clés, faites un paiement de test. Les commandes arrivent dans le même back-office que celles passées par l'API.
29Champs intégrés dans votre propre page
Quand le paiement doit se faire dans votre propre mise en page, intégrez directement les champs de paiement : les champs sont hébergés et couverts par PCI de notre côté, la page autour est entièrement la vôtre, et les données de carte ne touchent jamais vos serveurs.
30Usage unique, multiple, expiration
Un lien peut se fermer après un paiement ou continuer à encaisser — dans la démo, la place d'atelier a reçu 3 paiements, l'heure de consultation 6. Par défaut, les liens expirent au bout de 30 jours, et un lien expiré l'indique au lieu d'échouer en silence.
31Mode test
Les intégrations se testent sur des sessions de test, avec les cartes émises en même temps que vos clés sandbox, avant que quoi que ce soit de réel ne bouge. Les flux sont identiques : ce qui passe en test est ce qui part en production.
32Un routage lisible
Le trafic carte suit une politique de routage écrite dans des termes que vous connaissez — réseau de la carte, pays émetteur, devise, montant — et non une boîte noire. Vous voyez quelle route un paiement a empruntée, depuis l'écran même du paiement.
33Une seconde tentative avant la vente perdue
Un refus temporaire est retenté sur une route alternative dans la même session de checkout, avant que le client ne voie un échec. La plupart des paiements récupérés sont des paiements dont le client n'a jamais su qu'ils étaient menacés.
34Des refus en langage clair
Les codes bruts des émetteurs sont traduits en motifs exploitables par un opérateur — carte expirée, fonds insuffisants, risque émetteur — et regroupés pour qu'une tendance sur de nombreux paiements apparaisse comme telle.
353-D Secure en politique, pas en friction
La plupart des paiements passent sur les seuls signaux d'appareil et de comportement ; un challenge d'authentification renforcée apparaît quand la politique l'exige. Vous définissez la politique — systématique, selon le risque, ou exemption quand les règles le permettent — et la page hébergée gère le parcours.
36Une seule ligne à rapprocher
Checkout, reçu et règlement portent la même référence de commande. Qui cherche 9F21-0716 trouve une seule écriture de €49.00 — pas un enregistrement carte dans un système et un enregistrement crypto dans un autre.
37Règlement et virements
Le règlement s'énonce là où vous le configurez : conversion automatique en EUR, règlement sur RO49 •••• 0421, virement quotidien à 23:00. Le chiffre que le comptable verra demain se décide sur un écran que le marchand peut lire aujourd'hui.
38Un virement dont on remonte la trace
Chaque virement s'ouvre sur les commandes qui l'ont alimenté, frais détaillés. La ligne bancaire correspond à une liste exportable : la clôture de fin de mois devient une simple recherche, pas une enquête.
39Remboursements partiels
Le montant du remboursement est modifiable jusqu'au montant du paiement initial — le panneau affiche le maximum et traite tout montant inférieur comme un remboursement partiel. Dix remboursements partiels sur une commande se rapprochent toujours sur une seule référence.
40Motifs de remboursement au dossier
Chaque remboursement porte un motif obligatoire et une note facultative, et la note voyage : elle figure dans les exports et sur le reçu du client. Six mois plus tard, personne n'a à se rappeler pourquoi la commande 9F21-0716 a été régularisée.
41Envoi des reçus
Les reçus sont envoyés par e-mail au client et téléchargeables immédiatement ; les reçus de remboursement suivent le même chemin. Le marchand n'a jamais de modèle de reçu à créer.
42Annulation avant règlement
Annuler avant le lot du jour libère la retenue d'autorisation et aucun fonds ne bouge — ni remboursement, ni frais, rien à expliquer sur le relevé du client.
43Contrôles de risque activés par défaut
Les paiements par carte passent par 3-D Secure selon une politique de routage lisible. Les paiements par wallet reposent sur l'authentification propre à l'appareil, et les événements webhook sont vérifiés par signature avant d'être considérés comme fiables.
44Des règles écrites à votre façon
Les règles de filtrage se lisent comme des phrases — montant supérieur à X depuis le pays Y avec une carte jamais vue — et agissent en conséquence : autoriser, soumettre à un challenge ou bloquer. Les listes de cartes, d'e-mails et d'adresses de confiance ou bloqués se trouvent sur le même écran.
45Vélocité et signaux d'appareil
Les tentatives répétées depuis une même carte, un même appareil ou une même adresse sont détectées par des règles de fréquence, plutôt que remarquées plus tard par quelqu'un. Les signaux s'affichent sur le paiement, pas enfouis dans un score.
46Litiges avec les preuves jointes
Une contestation s'ouvre avec la commande qui la sous-tend : résultat d'autorisation, issue 3-D Secure, reçu, livraison, historique des remboursements. Répondez depuis cet écran : le dossier de preuves est constitué à partir des données, pas de mémoire.
47Les données de carte ne vous parviennent jamais
La page qui recueille les données de carte est la nôtre, hébergée et dans le périmètre PCI. Que le client paie sur notre domaine, sur le vôtre ou dans votre app, vos serveurs voient un token et une référence de commande — jamais un numéro de carte.
48Chiffrées au repos, dans l'UE
Les données de paiement sont chiffrées au repos et traitées dans l'UE. Pour un marchand européen, savoir où vivent les données est une réponse, pas une note de bas de page.
49Chaque action consignée
Remboursements, changements de moyen de paiement, changements de marque, rotations de clés — tout est inscrit dans une piste d'audit avec l'opérateur, l'horodatage et le motif. Les actions privilégiées exigent un motif avant de s'exécuter.
50Des rôles pour ceux qui en ont besoin
La finance voit les virements, le support voit les commandes et émet les remboursements, les développeurs voient les clés et les logs. L'accès s'accorde par rôle, sans partager un identifiant unique.
51Un annuaire clients
Les payeurs s'accumulent dans une vue clients — qui a payé, combien de fois, avec quel moyen — de sorte qu'un client récurrent soit une fiche, et non une coïncidence d'e-mails identiques dans des exports.
52Recherche et export CSV
Retrouvez un paiement par lien ou par référence depuis la barre de recherche ; exportez la vue courante en CSV quand la comptabilité le demande. Le back-office part du principe qu'un comptable finira par poser la question.
53Les chiffres, par jour et par moyen de paiement
Volume, taux d'acceptation, remboursements et répartition des moyens de paiement, sur la période de votre choix. De quoi savoir où est passé l'argent et quel moyen mérite d'être promu — sans rien exporter.
54La vue opérateur en coulisses
Gateway se branche à Protocore Center : le back-office des payment links y affiche chaque lien avec son virement de règlement rattaché et un lien d'ouverture dans Tracer pour la trace complète. Vos équipes ops voient à travers le checkout jusqu'au ledger.
55Whitelabel ou powered-by
Le checkout de démo appartient à Arc Studio SRL : son nom, sa marque, sa commande. Affichez-le avec un pied de page « powered by Protocore » ou en whitelabel intégral — dans les deux cas, la page est la vôtre.
