Comparer / Checkout
Checkout hébergé ou développé en interne
Tout marchand qui encaisse en ligne y répond une fois : la page qui collecte les données de carte vous appartient-elle, ou appartient-elle à votre prestataire ? La réponse détermine votre périmètre PCI, la rapidité avec laquelle vous ajoutez un moyen de paiement, et qui est réveillé quand les réseaux de cartes imposent une nouvelle obligation. C'est moins un choix technologique qu'une décision sur ce que votre équipe doit faire de son année.
Option contre option
Sept questions qui tranchent
Quand le checkout hébergé l'emporte
Pour la plupart des entreprises, la plupart du temps. Si les paiements sont votre façon d'être payé plutôt que ce que vous vendez, la page de checkout n'est pas là où se joue votre avantage — et le coût d'en être propriétaire se paie de la façon la moins visible : une part permanente de votre capacité d'ingénierie consacrée aux obligations des réseaux de cartes et aux intégrations de moyens de paiement plutôt qu'à votre produit. Une page hébergée règle aussi la question PCI, qui est le plus gros coût caché du développement en interne.
- 01Le paiement est un moyen d'encaisser, pas le produit lui-même
- 02Vous voulez les données de carte hors périmètre plutôt que soigneusement manipulées
- 03Les nouveaux moyens de paiement doivent arriver sans livraison de votre côté
- 04Vos ingénieurs valent plus sur ce que les clients achètent
Quand le développement maison l'emporte
Quand le checkout est vraiment le produit. Les plateformes qui encaissent pour le compte de tiers, les entreprises dont le parcours ne peut s'exprimer dans aucune page hébergée, et les équipes dont le volume est tel qu'une fraction de point de conversion pèse plus que le salaire d'une équipe paiement — ces cas existent, et ils justifient de construire. Tout comme une position réglementaire qui exige la surface de traitement des cartes dans votre propre périmètre. En deçà de cette échelle, construire revient généralement à redécouvrir, à grands frais, pourquoi les checkouts hébergés existent.
- 01Le paiement est le produit — vous encaissez pour le compte de tiers
- 02Le volume est assez élevé pour que la conversion marginale vaille plus que le coût d'une équipe
- 03Un régulateur ou un comité des risques exige la surface dans votre périmètre
- 04Votre parcours est vraiment atypique et aucune page hébergée ne peut l'exprimer
Où se place Protocore
Protocore Gateway est la réponse hébergée, avec les échappatoires habituelles intégrées plutôt que vendues à part : faites tourner la page sur notre domaine ou le vôtre, intégrez les champs de paiement dans votre propre mise en page quand le parcours l'exige, ou présentez le même checkout nativement dans votre app. Cartes, wallets, virement bancaire et USDC tiennent sur une seule page et se règlent en un seul montant en euros, rattaché à une seule référence de commande. Et si la vraie réponse pour vous est la troisième option — être le prestataire plutôt que le marchand — la même plateforme est disponible en whitelabel, ce qui est généralement plus avantageux que de construire une gateway de zéro.
- 01Page hébergée, domaine personnalisé, champs intégrés ou in-app — même intégration
- 02Cartes, wallets, virement et USDC sur une seule page, réglés en EUR
- 03Une seule référence de commande, du checkout au reçu jusqu'à la ligne bancaire
- 04Disponible en whitelabel pour être le prestataire, pas le marchand
Vous hésitez entre les deux ?
Dites-nous votre volume, vos moyens de paiement et sur quoi travaillent vos ingénieurs. Nous vous dirons franchement ce qui convient à votre situation — y compris quand c'est de le développer vous-même.