Non. Le comportement de l’API, les formats des demandes et des réponses, l’authentification et toutes les données de transaction demeurent les mêmes. Il s’agit uniquement d’un changement d’URL.

Cela dépend de la façon dont vous accédez aux services de Shift4.

Si vos systèmes se connectent directement aux points de terminaison d’API de Bambora/Beanstream (ce qui est généralement géré par un développeur interne, une agence de TI ou un fournisseur de logiciels tiers), ces intégrations doivent être mises à jour. Transmettez ce document à l’équipe technique appropriée.

Oui, mais il s’agit d’un petit changement. Si vous dirigez directement vos clients vers notre page de paiement hébergée, vous devrez mettre à jour le domaine dans cette URL. Votre identifiant de commerçant, le montant, les détails de la commande et tous les autres paramètres demeurent exactement les mêmes.

Avant : https://web.na.bambora.com/scripts/payment/payment.asp?merchant_id=123456789&trnAmount=19.99...

Après : https://checkout.bam.shift4api.net/scripts/payment/payment.asp?merchant_id=123456789&trnAmount=19.99...

Autrement dit, remplacez https://web.na.bambora.com par https://checkout.bam.shift4api.net. Le chemin et tout ce qui suit le point d’interrogation peuvent rester tels quels. Le nouveau domaine accepte également le chemin sans /scripts; les deux formats fonctionnent donc.

Si votre lien de paiement est codé en dur dans un site Web, un modèle de facture, un courriel ou un bouton, transmettez cette information à votre développeur ou à votre fournisseur de TI et demandez-lui de remplacer uniquement la partie du domaine.

Notre outil de création de liens génère maintenant des liens utilisant le nouveau domaine.

Faites suivre ce document et le courriel de migration original à votre fournisseur de logiciels ou au fournisseur de votre module d’extension. Demandez-lui de confirmer si son produit nécessite une mise à jour et à quel moment il prévoit la publier.

Vous devriez également confirmer auprès de lui, avant la date limite du 31 décembre 2026, que la mise à jour a été appliquée.

En tant qu’implantateur technique agissant au nom d’un commerçant, vous êtes responsable de ce qui suit :

• Mettre à jour toutes les URL des points de terminaison d’API dans l’intégration du commerçant, afin de remplacer les anciens domaines Bambora/Beanstream par la nouvelle convention de domaine de Shift4.
• Examiner et mettre à jour les listes d’autorisation du pare-feu avec le nouveau nom de domaine (*.bam.shift4api.net) ou les adresses IP (162.159.142.249 et 172.66.2.245), au besoin.
• Tester l’intégration mise à jour dans l’environnement de préproduction avant de la déployer en production.
• Terminer la migration avant le 31 décembre 2026.

Consultez la liste complète de mappage des points de terminaison ici pour connaître toutes les URL touchées.

Le processus de mise à jour dépend de la façon dont votre intégration est conçue, mais les étapes sont généralement les suivantes :

• Repérez toutes les références aux domaines Bambora/Beanstream dans votre base de code, vos fichiers de configuration, vos variables d’environnement et votre infrastructure (p. ex., DNS, équilibreur de charge, règles de pare-feu).
• Remplacez toutes les occurrences par le point de terminaison correspondant. Consultez la liste complète de mappage des points de terminaison ici.
• Mettez à jour toute configuration d’épinglage ou de validation des certificats TLS/SSL qui fait référence à l’ancien domaine.
• Mettez à jour les listes d’autorisation du pare-feu afin d’autoriser le trafic vers les nouvelles adresses IP (162.159.142.249 et 172.66.2.245) et le nom de domaine (*.bam.shift4api.net).
• Testez votre intégration dans un environnement de préproduction ou de bac à sable avant de la déployer en production.
• Déployez les changements en production avant le 31 décembre 2026.

Pour mettre à jour un lien existant, remplacez le domaine web.na.bambora.com par checkout.bam.shift4api.net. Le chemin, les paramètres de requête et hashValue restent les mêmes; vous n’avez donc pas besoin de régénérer le hachage. Le nouveau domaine accepte le chemin avec ou sans /scripts.

Si votre code génère des URL Checkout par programmation, mettez à jour l’URL de base dans votre code ou votre configuration. Le reste de votre logique de génération de liens n’a pas besoin d’être changé.

Ancienne URL Checkout :  https://web.na.bambora.com/scripts/payment/payment.asp?merchant_id=123456789&trnLanguage=eng&...

Nouvelle URL Checkout :  https://checkout.bam.shift4api.net/scripts/payment/payment.asp?merchant_id=123456789&trnLanguage=eng&...

Pour générer de nouveaux exemples de liens, utilisez notre outil de création de liens, qui génère maintenant le nouveau domaine.

La mise à jour des listes d’autorisation du pare-feu peut être nécessaire. Nos nouvelles adresses IP sont 162.159.142.249 et 172.66.2.245. Veuillez vous assurer que votre équipe de réseau ou de TI examine et mette à jour les règles de votre pare-feu afin d’autoriser ces adresses avant la date de mise en service du 31 décembre 2026.

Si votre pare-feu autorise actuellement le trafic par nom de domaine plutôt que par adresse IP, vous devrez ajouter le domaine *.bam.shift4api.net à votre liste d’autorisation.

Le point de terminaison bam.shift4api.net remonte jusqu’au certificat racine ISRG Root X2, délivré par l’Internet Security Research Group (l’organisation derrière Let’s Encrypt). Le certificat est joint à cet article sous le nom ISRG Root X2.crt.

Détails du certificat

Comment l’utiliser
Si votre application ou votre serveur ne fait pas déjà confiance à ISRG Root X2, ajoutez le certificat joint à votre magasin de certificats de confiance (keystore Java, magasin de certificats du système d’exploitation ou ensemble d’autorités de certification de votre client HTTP). La plupart des systèmes d’exploitation et des navigateurs modernes incluent déjà cette racine; de nombreuses intégrations ne nécessiteront donc aucune intervention.

Remarque : Seule la racine est nécessaire dans votre magasin de certificats de confiance. Les certificats intermédiaires sont envoyés par le serveur pendant la négociation TLS.

Non. Vos clés d’API, identifiants et méthodes d’authentification existants demeurent valides. Aucune nouvelle authentification ni rotation des identifiants n’est requise dans le cadre de cette migration.

Non. Les structures de toutes les demandes d’API, les formats de réponse, les codes d’erreur et les schémas de données demeurent identiques. Votre logique d’intégration existante n’a pas besoin d’être modifiée, à l’exception de la mise à jour de l’URL.

Nos SDK sont des produits existants et nous ne les prenons plus en charge depuis plus de cinq ans.

Nous vous recommandons soit de réintégrer nos API REST, soit de communiquer avec notre équipe des ventes pour discuter du passage à la plateforme Shift4.

Vous pouvez également repérer le baseURL dans le SDK et remplacer l’URL par https://api.bam.shift4api.net, puis effectuer vos paiements de test dans votre compte de test avant de le déployer dans vos comptes réels.

Nous recommandons les étapes de préparation suivantes :

• Consultez dès maintenant la liste de mappage des points de terminaison et déterminez quelles URL votre système utilise.
• Vérifiez votre base de code, vos pipelines CI/CD, vos configurations d’environnement et votre infrastructure en tant que code pour repérer les URL Bambora/Beanstream codées en dur.
• Mettez d’abord à jour vos environnements de préproduction et de développement, puis validez les fonctionnalités de bout en bout.
• Planifiez votre déploiement en production avant la date limite du 31 décembre 2026 afin de disposer de suffisamment de temps pour effectuer les tests.
• Coordonnez-vous avec les fournisseurs ou modules d’extension tiers pour confirmer qu’ils seront mis à jour à temps.

Après le 31 décembre 2026, les anciens points de terminaison seront désactivés de façon permanente et toutes les demandes envoyées aux anciennes URL commenceront à échouer. Vous devriez terminer la migration avant le 31 décembre 2026 afin d’éviter toute interruption.