Multicore : une continuité maximale pour chaque paiement

Cette évolution va au-delà de la seule infrastructure technique. PAY. rend les nouvelles fonctionnalités et fonctionnalités de paiement disponibles exclusivement sur la Multicore Platform. Pour les marchands et les partenaires d'intégration, cela signifie qu'il est important de maintenir leur intégration PAY. à jour.

Qu'est-ce que Multicore ?

Avec la Multicore Platform, PAY. peut traiter les transactions via plusieurs Transaction Gateway Units. Via connect.pay.nl, plusieurs TGU sont disponibles pour le traitement des transactions. Il existe par ailleurs d'autres cœurs (cores) qui peuvent notamment être utilisés comme route alternative ou de secours.

L'objectif est de disposer d'une infrastructure moderne et flexible pour le traitement des paiements. Une intégration Multicore à jour peut notamment bénéficier d'une disponibilité accrue, d'un accès à de nouvelles méthodes de paiement et d'un traitement des paiements plus rapide

Étant donné que le traitement des paiements constitue l'élément le plus important du processus de paiement (checkout), nous avons développé une plateforme multicœur qui se compose de :

• Transaction Gateway Units (TGU) : le traitement des paiements s'effectue dans l'un de nos systèmes Transaction Gateway Unit (TGU).

• Global Management System (GMS) : toutes les autres activités liées au traitement des paiements (comme les remboursements, les rapports sur les paiements, la modification des paramètres de traitement des paiements, la visibilité sur les versements et la facturation, etc.) passent par notre Global Management System (GMS).

Nous nous efforçons évidemment d'assurer une disponibilité élevée de l'ensemble de notre plateforme. Le traitement des paiements implique toutefois de nombreuses parties différentes. Si l'une de ces parties n'est pas disponible, la transaction risque d'être interrompue. Nous réacheminons les transactions via différents canaux, plusieurs processeurs et acquéreurs. Nous vous recommandons néanmoins de toujours sélectionner, dans la partie la plus importante du processus de paiement (le traitement du paiement) de votre intégration, au moins deux de nos TGU, voire plus, afin de limiter l'impact d'une perturbation.

Routage de secours (fallback)

PAY. peut acheminer les paiements d'intégrations plus anciennes via l'infrastructure Multicore. Cela nous permet de garantir que certaines fonctionnalités de la nouvelle plateforme puissent également être utilisées pour ces transactions.

Le routage n'équivaut pas à une prise en charge Multicore complète

Tous les marchands n'utilisent pas encore une intégration PAY. mise à jour pour Multicore. Lorsqu'un marchand utilise encore une intégration ancienne ou non mise à jour, PAY. peut acheminer les paiements vers l'infrastructure Multicore.

Ainsi, un marchand ne perd pas immédiatement l'accès aux nouvelles fonctionnalités. En arrière-plan, PAY. veille à ce que le paiement soit redirigé vers l'infrastructure sur laquelle ces fonctionnalités sont disponibles.

Ce routage ne doit toutefois pas être considéré comme un substitut à une intégration Multicore à jour. Pour ce routage supplémentaire, des frais supplémentaires par transaction peuvent être facturés.

En effet, les avantages en matière de disponibilité offerts par Multicore dépendent en partie de la manière dont l'intégration elle-même est configurée. PAY. recommande donc aux intégrations de pouvoir utiliser plusieurs TGU pour la partie la plus importante du checkout – le paiement proprement dit.

Les nouvelles fonctionnalités uniquement sur Multicore

PAY. développe en permanence la plateforme de paiement. Afin d'éviter que les nouvelles fonctionnalités ne doivent également être construites et maintenues sur des architectures techniques plus anciennes, les nouvelles fonctionnalités sont déployées exclusivement sur la Multicore Platform.

Cela signifie qu'un marchand disposant d'une intégration PAY. obsolète ne pourra pas, à terme, bénéficier automatiquement et directement de toutes les nouvelles possibilités.

PAY. peut, dans la mesure du possible, acheminer ces paiements afin que les fonctionnalités de la Multicore Platform puissent tout de même être appliquées. Cette couche de routage supplémentaire est toutefois destinée à servir de solution transitoire, et non d'alternative structurelle à la mise à jour d'une intégration.

Il ne s'agit donc explicitement pas de frais permettant à un marchand d'« acheter » automatiquement une disponibilité plus élevée. Le routage permet à PAY. de transmettre le paiement via l'infrastructure appropriée et, dans la mesure du possible, de rendre disponibles de nouvelles fonctionnalités.

La mise à jour reste la meilleure solution

Pour les marchands, la solution structurelle est donc simple : veillez à ce que l'intégration PAY. soit mise à jour vers une version actuelle prenant entièrement en charge la Multicore Platform.

Cela permet non seulement d'éviter des frais supplémentaires liés au traitement legacy, mais aussi de faire directement bénéficier l'intégration des développements futurs de la plateforme PAY.

Une intégration Multicore à jour donne accès à :

• de nouvelles fonctionnalités et fonctionnalités de paiement ;
• de nouvelles méthodes de paiement ;
• les API PAY. actuelles ;
• plusieurs Transaction Gateway Units ;
• de meilleures possibilités de secours (fallback) et de redondance ;
• d'autres optimisations dans le traitement des paiements.

PAY. conseille donc aux marchands et aux partenaires d'intégration technique de ne pas continuer à s'appuyer sur le routage des intégrations plus anciennes, mais de migrer activement leur connexion vers Multicore.

Multicore n'est pas seulement une voie pour les paiements, mais la base technique sur laquelle PAY. continue de développer sa plateforme de paiement.

La mise à jour vers Multicore est simple

La mise à jour d'une intégration PAY. existante vers Multicore ne doit pas nécessairement être un projet technique de grande ampleur. La structure et le fonctionnement du traitement des transactions sont en grande partie identiques à ceux de l'ancienne plateforme. Pour les intégrations existantes, cela signifie qu'une grande partie de la logique et des processus actuels peut être conservée.

Une reconstruction complète de l'intégration de paiement n'est donc, dans la plupart des cas, pas nécessaire. Il s'agit surtout de mettre à jour la connexion, afin que les transactions puissent être traitées directement via l'infrastructure Multicore.

Pour simplifier davantage la transition, PAY. met à disposition des SDK grâce auxquels les développeurs peuvent intégrer facilement l'API PAY. dans leur application. Une intégration existante peut ainsi être mise à jour relativement facilement vers la norme technique actuelle.

Nos plugins ont également été mis à jour

Utilisez-vous un plugin PAY. standard ? La transition est alors encore plus simple. Les plugins PAY. ont désormais été mis à jour pour la nouvelle infrastructure, et les versions actuelles peuvent d'ores et déjà être téléchargées.

Nous conseillons donc aux marchands utilisant un plugin PAY. de vérifier qu'ils ont installé la version la plus récente. En mettant à jour le plugin, l'intégration peut utiliser directement l'infrastructure PAY. actuelle, sans qu'il soit nécessaire de développer une toute nouvelle intégration de paiement.

Calendrier de migration

Afin d'accélérer la migration vers la nouvelle plateforme, nous ajoutons progressivement des coûts aux transactions qui transitent encore par l'ancienne plateforme. Le maintien de la plateforme legacy entraîne des coûts de gestion, de maintenance et d'exploitation supplémentaires. En répercutant progressivement ces coûts, nous créons une incitation financière claire à migrer en temps voulu et nous soutenons le retrait progressif complet, prévu en février 2027, de l'ancienne plateforme.